[Wien] DOS plot for FSM
Dear Prof. Blaha and Wien users,I am running FSM in Wien08. When i try to plot DOS, i found there are some problem exist according to UG and former mailing list questions, which guide me follow the sequence: run x lapw1 -up again, x lapw2-up -qtl; x lapw2 -dn -qtl and then put manually the two different E-fermi (from case.scf) into case.qtlup/dn respectively. i found it's works fine for spin up DOS plot, but not for spin down normally. ([Wien] Fixed-Magnetic-Moment Mon Mar 1 12:02:57 CET 2004)Only after a step of x lapw1 -dn is added before x lapw2 -dn -qtl, it could work well. I checked the case files, it is found that no case.vectordn_* files before x lapw1 -dn, thus case.qtldn is empty after run x lapw2 -dn -qtl. That's why i could not plot DOS of spin down.I just wondered whether it is right when i follow the new sequence: run x lapw1 -up again, x lapw2-up -qtl; x lapw1 -dn, x lapw2 -dn -qtl. Another tiny problem is that i could not receive any mails of Wien mailing li! st from Feb 22, 2008, although the mail address is in the safety list of my mail box. I changed another box of Yahoo, still the same problem beside the Wien degist could be received normally. Thanks very much !Xueli Wang Phys. Dept. ,Huazhong University of Science and TechnologyWuhan, 430074 P.R.China Email: wxlhust at msn.com Phone: +86-27-87557517Mobile: +86-27-63567852 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20080504/779279a6/attachment.html
[Wien] Local Rotation Problems
Dear Dear Wien2k users and dear Prof. Blaha, I have tried to rotation x,y by 45 degree around the z axis for a transition metal ion in an octahedron according to your direction in previous discussion: 1. NSYM=1 with identity in the first operation; 2. x kgen with full k-mesh; 3. x lapw1 -up/dn; 4. change Local Rotation Martrix; 5. x lapw2 -qtl -up/dn. It is okey for every none spin polarized calculation or MMTOT=0, but problem happened as we execute the sp calculation and even more problem for the none-zero MMTOT: 1. It can only be succeed without parallel calculation, such as we could use x lapw1 -up/dn, x lapw2 -qtl -up/dn, but not x lapw1 -up/dn -p, x lapw2 -qtl -up/dn -p; 2. As we check the QTL results after rotation in sp calculation, we found that the quantities is about 2 times of the "right" value; 3. We think that the local rotation can not change the charge density of the compound, so the x,y rotated by 45 degree will show an EXCHANGE in QTL between orbital dXY and dX2Y2, dZ2 should keep the SAME value as before, and the charge density will projected to the new orbital direction of dXZ, dYZ. The results of MMTOT=0 coincide with what we analysis, but not for none-zero MMTOT. I tried the same rotation in TiO2 for different MMTOT, it shows the same problem. How could we explain this calculation? Is there any error in our rotation? Below is the QTL results for Ti atom in TiO2 before and after rotation in the two condition of MMTOT=0 and MMTOT=2, the old local rotation matrix is LOCAL ROT MATRIX: 0.7071068 0.7071068 0.000 -0.7071068 0.7071068 0.000 0.000 0.000 1.000 and the new one is LOCAL ROT MATRIX: 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 S,P,D,F,PX,PY,PZ,D-Z2,D-X2Y2,D-XY,D-XZ,D-YZ MMTOT=0 Before QTL001: 1.0406 2.9865 0.6504 0.0232 0.9942 0.9941 0.9980 0.1061 0.1543 0.0958 0.2028 0.0915 QTL001: 1.0406 2.9865 0.6504 0.0232 0.9942 0.9941 0.9980 0.1061 0.1543 0.0958 0.2028 0.0915 After QTL001: 2.0813 5.9727 1.3008 0.0465 1.9883 1.9883 1.9961 0.2122 0.1916 0.3085 0.2943 0.2943 QTL001: 1.0407 2.9864 0.6504 0.0233 0.9942 0.9942 0.9981 0.1061 0.0958 0.1543 0.1472 0.1472 MMTOT=2 Before QTL001: 1.0394 2.9814 0.9011 0.0232 0.9924 0.9924 0.9966 0.1547 0.1968 0.2326 0.1751 0.1418 QTL001: 1.0380 2.9787 0.5225 0.0209 0.9909 0.9915 0.9964 0.0889 0.1270 0.0650 0.1733 0.0685 After QTL001: 2.0768 5.9613 1.0590 0.0459 1.9842 1.9842 1.9928 0.1834 0.1348 0.2586 0.2411 0.2411 QTL001: 1.0383 2.9812 0.5307 0.0234 0.9923 0.9923 0.9967 0.0900 0.0683 0.1274 0.1225 0.1225 Thank you in advance, Xueli Wang -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20091022/59d68c94/attachment.htm>
[Wien] Local Rotation Problems
Dear Prof. Blaha, Thanks for your reply. I did the spin-polarized and non-spin-polarized calculations with totally independent process from initialization in different directories, and ran spin-up and dn separately. I am also sure that i ran x lapw2 -up -qtl but not x lapw2 -qtl. I did try these for several examples but shows the similar results. Best regards, Xueli Wang > Date: Thu, 22 Oct 2009 15:04:21 +0200 > From: pblaha at theochem.tuwien.ac.at > To: wien at zeus.theochem.tuwien.ac.at > Subject: Re: [Wien] Local Rotation Problems > > I don't know what you are doing wrong. > > There is "no difference" between a spin-polarized and non-spin-polarized > calculation, except > that the effort doubles (you have to do it for spin-up and dn separately and > independently!!!) > and the normalization changes from 2 to 1. > > Did you mix spin-polarized and non-spinpolarized calculations in ONE > directory ??? > > Are you sure you ran x lapw2 -up -qtl ??? It looks as if you ran x > lapw2 -qtl > which gived the different normalization. > > Anyway, I'd try the qtl program for this purpose. > > > Xueli Wang schrieb: > > Dear Dear Wien2k users and dear Prof. Blaha, > > > > I have tried to rotation x,y by 45 degree around the z axis for a > > transition metal ion in an octahedron according > > to your direction in previous discussion: > > 1. NSYM=1 with identity in the first operation; > > 2. x kgen with full k-mesh; > > 3. x lapw1 -up/dn; > > 4. change Local Rotation Martrix; > > 5. x lapw2 -qtl -up/dn. > > > > It is okey for every none spin polarized calculation or MMTOT=0, but > > problem happened as we execute the > > sp calculation and even more problem for the none-zero MMTOT: > > 1. It can only be succeed without parallel calculation, such as we could > > use! > > x lapw1 -up/dn, x lapw2 -qtl -up/dn, > > but not x lapw1 -up/dn -p, x lapw2 -qtl -up/dn -p; > > 2. As we check the QTL results after rotation in sp calculation, we found > > that the quantities is about 2 times of > > the "right" value; > > 3. We think that the local rotation can not change the charge density of > > the compound, so the x,y rotated by > > 45 degree will show an EXCHANGE in QTL between orbital dXY and dX2Y2, dZ2 > > should keep the SAME value > > as before, and the charge density will projected to the new orbital > > direction of dXZ, dYZ. The results of MMTOT=0 > > coincide with what we analysis, but not for none-zero MMTOT. > > I tried the same rotation in TiO2 for different MMTOT, > > it shows the same problem. How could we explain this calculation? Is there > > any error in our rotation? > > > > Below is the QTL results for Ti atom in TiO2 before and after rotation in > > the two condition of MMTOT=0 and MMTOT=2, > > the old local rotation matrix is > > LOCAL ROT MATRIX: 0.7071068 0.7071068 0.000 > > -0.7071068 0.7071068 0.000 > >0.000 0.000 1.000 > > and the new one is > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > > > S,P,D,F,PX,PY,PZ,D-Z2,D-X2Y2,D-XY,D-XZ,D-YZ > > MMTOT=0 > > Before > > QTL001: 1.0406 2.9865 0.6504 0.0232 0.9942 0.9941 0.9980 0.1061 0.1543 > > 0.0958 0.2028 0.0915 > > QTL001: 1.0406 2.9865 0.6504 0.0232 0.9942 0.9941 0.9980 0.1061 0.1543 > > 0.0958 0.2028 0.0915 > > After > > QTL001: 2.0813 5.9727 1.3008 0.0465 1.9883 1.9883 1.9961 0.2122 0.1916 > > 0.3085 0.2943 0.2943 > > QTL001: 1.0407 2.9864 0.6504 0.0233 0.9942 0.9942 0.9981 0.1061 0.0958 > > 0.1543 0.1472 0.1472 > > > > MMTOT=2 > > Before > > QTL001: 1.0394 2.9814 0.9011 0.0232 0.9924 0.9924 0.9966 0.1547 0.1968 > > 0.2326 0.1751 0.1418 > > QTL001: 1.0380 2.9787 0.5225 0.0209 0.9909 0.9915 0.9964 0.0889 0.1270 > > 0.0650 0.1733 0.0685 > > After > > QTL001: 2.0768 5.9613 1.0590 0.0459 1.9842 1.9842 1.9928 0.1834 0.1348 > > 0.2586 0.2411 0.2411 > > QTL001: 1.0383 2.9812 0.5307 0.0234 0.9923 0.9923 0.9967 0.0900 0.0683 > > 0.1274 0.1225 0.1225 > > > > Thank you in advance, > > Xueli Wang > > > > > > > > > > ___ > > Wien mailing list > > Wien at zeus.theochem.tuwien.ac.at > > http://zeus.theochem.tuwien.ac
[Wien] Local Rotation Problems
Dear Prof. Blaha,I changed the version from wien0803 into wien0902, and obtained the same strange value. I believethere is a little bug in qtl. It can be justified from the total d electrons variation and the change ofMMTOT before and after rotation.By detailed investigation, i found that the DOS plot shows a good consistency with the rotation features,where the orbital D-Z2 keeps the same as old one, orbitals D-X2Y2 and D-XY is exchanged. And i alsofound that the qtl problem comes from the inappropriate fermi energy in spin-polarized calculation. Wouldyou please suggest me a method to get the right QTL value by the right fermi energy?Thanks for your attention.Best regards,Xueli Wang From: wxlh...@msn.com To: wien at zeus.theochem.tuwien.ac.at Date: Thu, 22 Oct 2009 22:47:22 +0800 Subject: Re: [Wien] Local Rotation Problems Dear Prof. Blaha, Thanks for your reply. I did the spin-polarized and non-spin-polarized calculations with totally independent process from initialization in different directories, and ran spin-up and dn separately. I am also sure that i ran x lapw2 -up -qtl but not x lapw2 -qtl. I did try these for several examples but shows the similar results. Best regards, Xueli Wang > Date: Thu, 22 Oct 2009 15:04:21 +0200 > From: pblaha at theochem.tuwien.ac.at > To: wien at zeus.theochem.tuwien.ac.at > Subject: Re: [Wien] Local Rotation Problems > > I don't know what you are doing wrong. > > There is "no difference" between a spin-polarized and non-spin-polarized ca! lculation, except > that the effort doubles (you have to do it for spin-up and dn separately and > independently!!!) > and the normalization changes from 2 to 1. > > Did you mix spin-polarized and non-spinpolarized calculations in ONE > directory ??? > > Are you sure you ran x lapw2 -up -qtl ??? It looks as if you ran x > lapw2 -qtl > which gived the different normalization. > > Anyway, I'd try the qtl program for this purpose. > > > Xueli Wang schrieb: > > Dear Dear Wien2k users and dear Prof. Blaha, > > > > I have tried to rotation x,y by 45 degree around the z axis for a > > transition metal ion in an octahedron according > > to your direction in previous discussion: > > 1. NSYM=1 with identity in the first operation; > > 2. x kgen with full k-mesh; > > 3. x lapw1 -up/dn; > > 4. change Local Rotation Martrix; > > 5. x ! lapw2 -qtl -up/dn. > > > > It is okey for every non e spin polarized calculation or MMTOT=0, but problem happened as we execute the > > sp calculation and even more problem for the none-zero MMTOT: > > 1. It can only be succeed without parallel calculation, such as we could > > use! > > x lapw1 -up/dn, x lapw2 -qtl -up/dn, > > but not x lapw1 -up/dn -p, x lapw2 -qtl -up/dn -p; > > 2. As we check the QTL results after rotation in sp calculation, we found > > that the quantities is about 2 times of > > the "right" value; > > 3. We think that the local rotation can not change the charge density of > > the compound, so the x,y rotated by > > 45 degree will show an EXCHANGE in QTL between orbital dXY and dX2Y2, dZ2 > > should keep the SAME value > > as before, and the charge density will projected to the new orbital > > direction of dXZ, dYZ. The results of MMTOT=0 > > coincide with what we analysis, but not for none-zero MMTOT. > > I tried the same r! otation in TiO2 for different MMTOT, > > it shows the same problem. How could we explain this calculation? Is there > > any error in our rotation? > > > > Below is the QTL results for Ti atom in TiO2 before and after rotation in > > the two condition of MMTOT=0 and MMTOT=2, > > the old local rotation matrix is > > LOCAL ROT MATRIX: 0.7071068 0.7071068 0.000 > > -0.7071068 0.7071068 0.000 > >0.000 0.000 1.000 > > and the new one is > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > > > S,P,D,F,PX,PY,PZ,D-Z2,D-X2Y2,D-XY,D-XZ,D-YZ > > MMTOT=0 > > Before > > QTL001: 1.0406 2.9865 0.6504 0.0232 0.9942 0.9941 0.9980 0.1061 0.1543 > > 0.0958 0.2! 028 0.0915 > > QTL001: 1.0406 2.9865 0.6504 0.0232 0.9942 0.9 941 0.9980 0.1061 0.1543 0.0958 0.2028 0.0915 > > After > > QTL001: 2.0813 5.9727 1.3008 0.0465 1.9883 1.9883 1.9961 0.2122 0.1916 > > 0.3085 0.2943 0.2943 > > QTL001: 1.0407 2.9864 0.6504 0.0233 0.9942 0.9942 0.9981 0.1061 0.0958 > > 0.1543 0.1472 0.1472 > > > > MMTOT=2 > > Before
[Wien] A Valid .machines file
The same problem happened to me. But when I try to reform the .machines file into the following ones, it can be worked: 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 Granularity:1 Extrafine:1 Best wishes, Xueli Wang From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Tue, 27 Apr 2010 13:38:23 +0530 Subject: [Wien] A Valid .machines file Dear Wien2k users, If we make the following changes in the .machines file 1:nx80:8 #nx80 is the node with 8 processors #8 represents 8 processors Granularity:1 Extrafine:1 The lapw1 job crashes Can anybody tell me as to how we can make the .machine file work? Suddhasattwa Ghosh -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100427/237321e7/attachment.htm>
[Wien] A Valid .machines file
And you can try to modify the number after Granularity, if you want to use the form of 1:nx80:8, the problem can also be resolved. 1:nx80:8 Granularity:8 Extrafine:1 Best regards, Xueli Wang From: wxlh...@msn.com To: wien at zeus.theochem.tuwien.ac.at Date: Tue, 27 Apr 2010 16:34:05 +0800 Subject: Re: [Wien] A Valid .machines file The same problem happened to me. But when I try to reform the .machines file into the following ones, it can be worked: 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 Granularity:1 Extrafine:1 Best wishes, Xueli Wang From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Tue, 27 Apr 2010 13:38:23 +0530 Subject: [Wien] A Valid .machines file Dear Wien2k users, If we make the following changes in the .machines file 1:nx80:8 #nx80 is the node with 8 processors #8 represents 8 processors Granularity:1 Extrafine:1 The lapw1 job crashes Can anybody tell me as to how we can make the .machine file work? Suddhasattwa Ghosh -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100427/9e90d0cb/attachment.htm>
[Wien] A Valid .machines file
Dear Suddhasattwa, MPICH2 installation is required for the form of 1:nx:8. Best Regards, Xueli From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Thu, 29 Apr 2010 09:12:45 +0530 Subject: Re: [Wien] A Valid .machines file Dear Xeuli The machines file 1:nx:8 Granularity:8 Extrafine:8 Does not seem to work. However, if I put 1:nx80 1:nx80 ?.. ?? Granularity:1 Extrafine:1 There are currently no problems. With the best regards Suddhasattwa Ghosh From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of Xueli Wang Sent: Tuesday, April 27, 2010 2:04 PM To: wien at zeus.theochem.tuwien.ac.at Subject: Re: [Wien] A Valid .machines file The same problem happened to me. But when I try to reform the .machines file into the following ones, it can be worked: 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 Granularity:1 Extrafine:1 Best wishes, Xueli Wang From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Tue, 27 Apr 2010 13:38:23 +0530 Subject: [Wien] A Valid .machines file Dear Wien2k users, If we make the following changes in the .machines file 1:nx80:8 #nx80 is the node with 8 processors #8 represents 8 processors Granularity:1 Extrafine:1 The lapw1 job crashes Can anybody tell me as to how we can make the .machine file work? Suddhasattwa Ghosh -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100429/2e8e5cf6/attachment.htm>
[Wien] A Valid .machines file
Dear Suddhasattwa, A file named stderr should be existed in this address but does not appear in your computer. Best Regards, Xueli From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Thu, 29 Apr 2010 14:14:20 +0530 Subject: Re: [Wien] A Valid .machines file Dear Xueli, Thanks for the mail It works well but there is a message in the STDOUT /dev/stderr: no such device or address What does this mean SG From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of Xueli Wang Sent: Thursday, April 29, 2010 9:42 AM To: wien at zeus.theochem.tuwien.ac.at Subject: Re: [Wien] A Valid .machines file Dear Suddhasattwa, MPICH2 installation is required for the form of 1:nx:8. Best Regards, Xueli From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Thu, 29 Apr 2010 09:12:45 +0530 Subject: Re: [Wien] A Valid .machines file Dear Xeuli The machines file 1:nx:8 Granularity:8 Extrafine:8 Does not seem to work. However, if I put 1:nx80 1:nx80 ?.. ?? Granularity:1 Extrafine:1 There are currently no problems. With the best regards Suddhasattwa Ghosh From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of Xueli Wang Sent: Tuesday, April 27, 2010 2:04 PM To: wien at zeus.theochem.tuwien.ac.at Subject: Re: [Wien] A Valid .machines file The same problem happened to me. But when I try to reform the .machines file into the following ones, it can be worked: 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 1:nx80 Granularity:1 Extrafine:1 Best wishes, Xueli Wang From: ssgh...@igcar.gov.in To: wien at zeus.theochem.tuwien.ac.at Date: Tue, 27 Apr 2010 13:38:23 +0530 Subject: [Wien] A Valid .machines file Dear Wien2k users, If we make the following changes in the .machines file 1:nx80:8 #nx80 is the node with 8 processors #8 represents 8 processors Granularity:1 Extrafine:1 The lapw1 job crashes Can anybody tell me as to how we can make the .machine file work? Suddhasattwa Ghosh -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100429/7c621d65/attachment.htm>