[Wien] Problem with geometry minimzation
Dear Prof. Blaha, I'm quite sure that my struct file is correct. The initail coordinates (as well as lattice parameters) have been taken from experiment. Before restarting the min_lapw calculation, I do remove histories (*broyd* and *tmpM files). Below, you can find the summary of (one of) my min_lapw calculation: grep :FGL001 *mini :FGL001: 1.ATOM 0.0 0.032.48700 total forces :FGL001: 1.ATOM 0.0 0.0 -16.04200 total forces :FGL001: 1.ATOM 0.0 0.023.58600 total forces :FGL001: 1.ATOM 0.0 0.028.77500 total forces :FGL001: 1.ATOM 0.0 0.030.82700 total forces :FGL001: 1.ATOM 0.0 0.032.11200 total forces :FGL001: 1.ATOM 0.0 0.032.68000 total forces :FGL001: 1.ATOM 0.0 0.032.56100 total forces :FGL001: 1.ATOM 0.0 0.032.52100 total forces :FGL001: 1.ATOM 0.0 0.032.48000 total forces :FGL001: 1.ATOM 0.0 0.032.48700 total forces :FGL001: 1.ATOM 0.0 0.032.48100 total forces :FGL001: 1.ATOM 0.0 0.032.47900 total forces :FGL001: 1.ATOM 0.0 0.032.48200 total forces :FGL001: 1.ATOM 0.0 0.032.48200 total forces :FGL001: 1.ATOM 0.0 0.032.48300 total forces greo :ENE *mini :ENE : ** TOTAL ENERGY IN Ry = -115360.01623115 :ENE : ** TOTAL ENERGY IN Ry = -115360.00155884 :ENE : ** TOTAL ENERGY IN Ry = -115360.01556490 :ENE : ** TOTAL ENERGY IN Ry = -115360.01607046 :ENE : ** TOTAL ENERGY IN Ry = -115360.01617964 :ENE : ** TOTAL ENERGY IN Ry = -115360.0162 :ENE : ** TOTAL ENERGY IN Ry = -115360.01622196 :ENE : ** TOTAL ENERGY IN Ry = -115360.01622583 :ENE : ** TOTAL ENERGY IN Ry = -115360.01622870 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623005 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623105 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623106 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623060 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623080 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623077 :ENE : ** TOTAL ENERGY IN Ry = -115360.01623087 grep :POS001 *mini :POS001: ATOM -1 POSITION = 0.7 0.3 0.63941 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.64764 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.64148 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.64027 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63979 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63958 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63949 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63945 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63943 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63942 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63941 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63941 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63941 MULTIPLICITY = 2 ZZ= 52.000 Te1 :POS001: ATOM -1 POSITION = 0.7 0.3 0.63941
[Wien] Problem with geometry minimzation
Ok. From this you can clearly see that E-tot and FGL does not fit together. Smaller forces give less negative E-tot. (At least if forces on other atoms do not destroy this simple logic) and since PORT minimizes E-tot, it finishes, although it has non-zero forces. Well, for those steps the total forces on other atoms are large and that's the reason why E-tot is less negative. For example in the second step, the total forces on all atoms are as follows: :FGL001: 1.ATOM 0.0 0.0 -16.04200 total forces :FGL002: 2.ATOM 0.0 0.041.64200 total forces :FGL003: 3.ATOM 0.0 0.010.71000 total forces and accordingly in this steps :ENE is the highest. I'm quite sure that my struct file is correct. The initail coordinates (as well as lattice parameters) have been taken from experiment. Before restarting the min_lapw calculation, This does not say anything. Is R0 ok ? RMTs set properly ? R0=0.0001 and RMT=2.5 (for all three atoms). Once again, there is no touching between the MT's I do remove histories (*broyd* and *tmpM files). Below, you can find the summary of (one of) my min_lapw calculation: Is it always like this, or other runs are different ? I always remove the histories before restarting min_lapw with a new case.inM If yes, the problem must be somewhere else and again, without testing myself, I cannot give more than the standard hints, although the problem may stem from something completely different ( Are you using the latest WIEN2k version and have followed all bug-fixes discussed on the mailing list ?) My current version of WIEN2K is 10. Anyway, using this version of WIEN2K, I have been able to do geometry optimization for other systems without any problem. This almost always means that the user (you) has set the IDFT problem up incorrectly -- GIGO. Have you read the optimization notes at http://www.wien2k.at/reg_user/textbooks/ ? Do you have almost touching spheres, bad RKMAX, k-points etc? -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101103/7d240679/attachment.htm
[Wien] Problem with geometry minimzation
Dear Laurence, Thanks a lot. That was indeed the reason why I couldn't optimize the atomic positions. Reducing (!) R0 to 0.1, I could successfully minimize all the forces. Now they're all well below 1.0 mRy/a.u.. By the way, you said that my initial R0 was too small, but I had to further reduce it in order to get min_lapw working! Am I picking up wrong R0 for Te!? (UG says it should be between 0.0005 to 0.5) Thanks again, Saeed Bahramy On Nov 3, 2010, at 3:08 AM, Laurence Marks wrote: Te, R0 is too small. 2010/11/2 Saeed Bahramy bahramy at riken.jp: Ok. From this you can clearly see that E-tot and FGL does not fit together. Smaller forces give less negative E-tot. (At least if forces on other atoms do not destroy this simple logic) and since PORT minimizes E-tot, it finishes, although it has non-zero forces. Well, for those steps the total forces on other atoms are large and that's the reason why E-tot is less negative. For example in the second step, the total forces on all atoms are as follows: :FGL001: 1.ATOM 0.0 0.0 -16.04200 total forces :FGL002: 2.ATOM 0.0 0.0 41.64200 total forces :FGL003: 3.ATOM 0.0 0.0 10.71000 total forces and accordingly in this steps :ENE is the highest. I'm quite sure that my struct file is correct. The initail coordinates (as well as lattice parameters) have been taken from experiment. Before restarting the min_lapw calculation, This does not say anything. Is R0 ok ? RMTs set properly ? R0=0.0001 and RMT=2.5 (for all three atoms). Once again, there is no touching between the MT's I do remove histories (*broyd* and *tmpM files). Below, you can find the summary of (one of) my min_lapw calculation: Is it always like this, or other runs are different ? I always remove the histories before restarting min_lapw with a new case.inM If yes, the problem must be somewhere else and again, without testing myself, I cannot give more than the standard hints, although the problem may stem from something completely different ( Are you using the latest WIEN2k version and have followed all bug-fixes discussed on the mailing list ?) My current version of WIEN2K is 10. Anyway, using this version of WIEN2K, I have been able to do geometry optimization for other systems without any problem. This almost always means that the user (you) has set the IDFT problem up incorrectly -- GIGO. Have you read the optimization notes at http://www.wien2k.at/reg_user/textbooks/ ? Do you have almost touching spheres, bad RKMAX, k-points etc? -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] Problem with geometry minimzation
w2web sets R0 automatically to a correct value. And WIEN2k_10 complains during init_lapw if R0 is too big ! Am 02.11.2010 20:37, schrieb Saeed Bahramy: Dear Laurence, Thanks a lot. That was indeed the reason why I couldn't optimize the atomic positions. Reducing (!) R0 to 0.1, I could successfully minimize all the forces. Now they're all well below 1.0 mRy/a.u.. By the way, you said that my initial R0 was too small, but I had to further reduce it in order to get min_lapw working! Am I picking up wrong R0 for Te!? (UG says it should be between 0.0005 to 0.5) Thanks again, Saeed Bahramy On Nov 3, 2010, at 3:08 AM, Laurence Marks wrote: Te, R0 is too small. 2010/11/2 Saeed Bahramy bahramy at riken.jp: Ok. From this you can clearly see that E-tot and FGL does not fit together. Smaller forces give less negative E-tot. (At least if forces on other atoms do not destroy this simple logic) and since PORT minimizes E-tot, it finishes, although it has non-zero forces. Well, for those steps the total forces on other atoms are large and that's the reason why E-tot is less negative. For example in the second step, the total forces on all atoms are as follows: :FGL001: 1.ATOM 0.0 0.0 -16.04200 total forces :FGL002: 2.ATOM 0.0 0.0 41.64200 total forces :FGL003: 3.ATOM 0.0 0.0 10.71000 total forces and accordingly in this steps :ENE is the highest. I'm quite sure that my struct file is correct. The initail coordinates (as well as lattice parameters) have been taken from experiment. Before restarting the min_lapw calculation, This does not say anything. Is R0 ok ? RMTs set properly ? R0=0.0001 and RMT=2.5 (for all three atoms). Once again, there is no touching between the MT's I do remove histories (*broyd* and *tmpM files). Below, you can find the summary of (one of) my min_lapw calculation: Is it always like this, or other runs are different ? I always remove the histories before restarting min_lapw with a new case.inM If yes, the problem must be somewhere else and again, without testing myself, I cannot give more than the standard hints, although the problem may stem from something completely different ( Are you using the latest WIEN2k version and have followed all bug-fixes discussed on the mailing list ?) My current version of WIEN2K is 10. Anyway, using this version of WIEN2K, I have been able to do geometry optimization for other systems without any problem. This almost always means that the user (you) has set the IDFT problem up incorrectly -- GIGO. Have you read the optimization notes at http://www.wien2k.at/reg_user/textbooks/ ? Do you have almost touching spheres, bad RKMAX, k-points etc? -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Peter Blaha Inst.Materialchemie, TU Wien Getreidemarkt 9 A-1060 Vienna Austria
[Wien] Problem with geometry minimzation
But I used w2web to create my struct file, and the initial R0 (0.0001) was actually the one set by w2web. And as far as I know, there was no such a complain during init_lapw. BTW, thanks again for your helpful comments and feedbacks, Saeed Bahramy On Nov 3, 2010, at 8:16 AM, Peter Blaha wrote: w2web sets R0 automatically to a correct value. And WIEN2k_10 complains during init_lapw if R0 is too big ! Am 02.11.2010 20:37, schrieb Saeed Bahramy: Dear Laurence, Thanks a lot. That was indeed the reason why I couldn't optimize the atomic positions. Reducing (!) R0 to 0.1, I could successfully minimize all the forces. Now they're all well below 1.0 mRy/a.u.. By the way, you said that my initial R0 was too small, but I had to further reduce it in order to get min_lapw working! Am I picking up wrong R0 for Te!? (UG says it should be between 0.0005 to 0.5) Thanks again, Saeed Bahramy On Nov 3, 2010, at 3:08 AM, Laurence Marks wrote: Te, R0 is too small. 2010/11/2 Saeed Bahramy bahramy at riken.jp: Ok. From this you can clearly see that E-tot and FGL does not fit together. Smaller forces give less negative E-tot. (At least if forces on other atoms do not destroy this simple logic) and since PORT minimizes E-tot, it finishes, although it has non-zero forces. Well, for those steps the total forces on other atoms are large and that's the reason why E-tot is less negative. For example in the second step, the total forces on all atoms are as follows: :FGL001: 1.ATOM 0.0 0.0 -16.04200 total forces :FGL002: 2.ATOM 0.0 0.0 41.64200 total forces :FGL003: 3.ATOM 0.0 0.0 10.71000 total forces and accordingly in this steps :ENE is the highest. I'm quite sure that my struct file is correct. The initail coordinates (as well as lattice parameters) have been taken from experiment. Before restarting the min_lapw calculation, This does not say anything. Is R0 ok ? RMTs set properly ? R0=0.0001 and RMT=2.5 (for all three atoms). Once again, there is no touching between the MT's I do remove histories (*broyd* and *tmpM files). Below, you can find the summary of (one of) my min_lapw calculation: Is it always like this, or other runs are different ? I always remove the histories before restarting min_lapw with a new case.inM If yes, the problem must be somewhere else and again, without testing myself, I cannot give more than the standard hints, although the problem may stem from something completely different ( Are you using the latest WIEN2k version and have followed all bug-fixes discussed on the mailing list ?) My current version of WIEN2K is 10. Anyway, using this version of WIEN2K, I have been able to do geometry optimization for other systems without any problem. This almost always means that the user (you) has set the IDFT problem up incorrectly -- GIGO. Have you read the optimization notes at http://www.wien2k.at/reg_user/textbooks/ ? Do you have almost touching spheres, bad RKMAX, k-points etc? -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Peter Blaha Inst.Materialchemie, TU Wien Getreidemarkt 9 A-1060 Vienna Austria ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] After SO band structure calculation error
Dear all ,
I am calculating the SO calculation of a double
perovskite compound using wien2k package. I have done the all the steps
according to userguide. I had made case.klist_band from xcrysden. I have run
x lapw1 -up -band
x lapw1 -dn -band
x lapwso -up -band
After last run I am getting the following error
{ ERROR IN OPENING UNIT: 9
FILENAME:
./LCMO.vectordn
STATUS: old FORM:unformatted
OPEN FAILED
0.001u 0.000s 0:00.08 0.0% 0+0k 0+0io 14pf+0w}
I donot understand what is the difficulty in running if all inputs are
correct. Could u please give me any suggestion to overcome the difficulty.
Thanks.
Santu Baidya
SNBNCBS,JRF
KOLKATA
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101103/0f4a0df9/attachment.htm
[Wien] force minimization method change from PORT to NEWT
Dear wien2k users, We have started force minimization of a material by using PORT minimization method. After 1st SCF it was displayed that the force is not converged. Although charge and energy were converged upto ~ 0.005 in this 1st SCF. We then edit the case.inM file *to change PORT minimization method in NEWT minimization method*. We use the command *min -NI -j 'runsp_lapw -I -i 40 -fc 1.0 '* . We have used the -NI switch as we want to start our calculation from the converged charge density as obtained in 1st SCF (with PORT miniization method). Now my question is :: (1) Should we start from the scratch (i.e not using -NI switch) when we change the PORT to NEWT? (2) If it happen that initially some structure say case_1.struct, case_2.struct, case_3.struct are obtained through PORT method and then the calculation get stopped due to not getting the convergence of force,.then should we use -NI switch if we change PORT to NEWT? Any response will be very helpful for us. Thanks in advance. with best regards, -- Shamik Chakrabarti Research Scholar Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 INDIA -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101103/01f5a410/attachment.htm
[Wien] Problem in a very simple calculation
Hi all, I am having a problem in running a very simple calculation - an scf cycle for fcc Si. I had set up a file for fcc Si and I had ran it successfully, until I realized that the space group found through init_lapw was not correct. Then I set the calculation up again, and this time, the space group is found correctly. But now that everything is set up correctly, I get an error when executing run_lapw in the second SCF cycle (lapw0 - lapw1 - lapw2 - core - mixer): hup: Command not found. Invalid null command. LAPW0 END Invalid null command. forrtl: severe (24): end-of-file during read, unit 5, file /home/mverissi/WIEN2k/fcc_Si/fcc_Si.in1 Image PCRoutineLineSource lapw1 00515D3D Unknown Unknown Unknown lapw1 00514845 Unknown Unknown Unknown lapw1 004B57E0 Unknown Unknown Unknown lapw1 0046EFEA Unknown Unknown Unknown lapw1 0046E7E0 Unknown Unknown Unknown lapw1 00493A1C Unknown Unknown Unknown lapw1 0042FF33 inilpw_ 362 inilpw.f lapw1 00432773 MAIN__ 42 lapw1_tmp_.F lapw1 00404C4C Unknown Unknown Unknown libc.so.6 2B65BB2FB5A6 Unknown Unknown Unknown lapw1 00404B49 Unknown Unknown Unknown If I cat the file fcc_Si.in1, it only gives me EF=0.35199 (WFFIL, WFPRI, ENFIL, SUPWF) while the other .in1* (fcc_Si.in1c and fcc_Si.in1_st) files give me both WFFIL EF= 0.5 (WFFIL, WFPRI, ENFIL, SUPWF) 7.00 104 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.302 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 00.30 0.000 CONT 1 10.30 0.000 CONT 1 0.302 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 00.30 0.000 CONT 1 10.30 0.000 CONT 1 K-VECTORS FROM UNIT:4 -9.0 2.510 red emin/emax/nband Now, The only difference from now to the case where the space group was wrong is that the space group fcc Si, 216, has no inversion symmetry, so it would require a complex calculation. For the other calculation, where the space group was wrong, inversion symmetry was indeed present, and it runs perfectly. Looking at the dayfile, indeed: start (Wed Nov 3 16:29:43 CET 2010) with lapw0 (40/99 to go) cycle 1 (Wed Nov 3 16:29:43 CET 2010) (40/99 to go) lapw0 (16:29:43) 1.2u 0.0s 0:01.31 100.7% 0+0k 0+520io 0pf+0w lapw1 -c (16:29:45) 1.7u 0.2s 0:02.01 99.5% 0+0k 0+9464io 0pf+0w lapw2 -c (16:29:47) 0.5u 0.0s 0:00.57 101.7% 0+0k 0+544io 0pf+0w lcore (16:29:47) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+248io 0pf+0w mixer (16:29:47) 0.0u 0.0s 0:00.02 200.0% 0+0k 0+768io 0pf+0w :ENERGY convergence: 0 0.0001 0 :CHARGE convergence: 0 0. 0 ec cc and fc_conv 0 1 1 cycle 2 (Wed Nov 3 16:29:47 CET 2010) (39/98 to go) lapw0 (16:29:47) 1.2u 0.0s 0:01.27 100.7% 0+0k 0+488io 0pf+0w lapw1 (16:29:49) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+8io 0pf+0w error: command /usr/local/software/install/Wien2K-ifort11.1/lapw1 lapw1.def failed stop error So it starts the first scf step by executing a complex calculation, as it should be for the case where no inversion symmetry is present, but in the second step it calls a real calculation. What files should be corrected in order to fix this bug? Best regards, Marcos -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101103/03ebadd2/attachment.htm
[Wien] Problem in a very simple calculation
Sorry for that... Just found the solution in the mailing list... Marcos 2010/11/3 Marcos Ver?ssimo Alves marcos.verissimo.alves at gmail.com Hi all, I am having a problem in running a very simple calculation - an scf cycle for fcc Si. I had set up a file for fcc Si and I had ran it successfully, until I realized that the space group found through init_lapw was not correct. Then I set the calculation up again, and this time, the space group is found correctly. But now that everything is set up correctly, I get an error when executing run_lapw in the second SCF cycle (lapw0 - lapw1 - lapw2 - core - mixer): hup: Command not found. Invalid null command. LAPW0 END Invalid null command. forrtl: severe (24): end-of-file during read, unit 5, file /home/mverissi/WIEN2k/fcc_Si/fcc_Si.in1 Image PCRoutineLineSource lapw1 00515D3D Unknown Unknown Unknown lapw1 00514845 Unknown Unknown Unknown lapw1 004B57E0 Unknown Unknown Unknown lapw1 0046EFEA Unknown Unknown Unknown lapw1 0046E7E0 Unknown Unknown Unknown lapw1 00493A1C Unknown Unknown Unknown lapw1 0042FF33 inilpw_ 362 inilpw.f lapw1 00432773 MAIN__ 42 lapw1_tmp_.F lapw1 00404C4C Unknown Unknown Unknown libc.so.6 2B65BB2FB5A6 Unknown Unknown Unknown lapw1 00404B49 Unknown Unknown Unknown If I cat the file fcc_Si.in1, it only gives me EF=0.35199 (WFFIL, WFPRI, ENFIL, SUPWF) while the other .in1* (fcc_Si.in1c and fcc_Si.in1_st) files give me both WFFIL EF= 0.5 (WFFIL, WFPRI, ENFIL, SUPWF) 7.00 104 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.302 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 00.30 0.000 CONT 1 10.30 0.000 CONT 1 0.302 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 00.30 0.000 CONT 1 10.30 0.000 CONT 1 K-VECTORS FROM UNIT:4 -9.0 2.510 red emin/emax/nband Now, The only difference from now to the case where the space group was wrong is that the space group fcc Si, 216, has no inversion symmetry, so it would require a complex calculation. For the other calculation, where the space group was wrong, inversion symmetry was indeed present, and it runs perfectly. Looking at the dayfile, indeed: start (Wed Nov 3 16:29:43 CET 2010) with lapw0 (40/99 to go) cycle 1 (Wed Nov 3 16:29:43 CET 2010) (40/99 to go) lapw0 (16:29:43) 1.2u 0.0s 0:01.31 100.7% 0+0k 0+520io 0pf+0w lapw1 -c (16:29:45) 1.7u 0.2s 0:02.01 99.5% 0+0k 0+9464io 0pf+0w lapw2 -c (16:29:47) 0.5u 0.0s 0:00.57 101.7% 0+0k 0+544io 0pf+0w lcore (16:29:47) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+248io 0pf+0w mixer (16:29:47) 0.0u 0.0s 0:00.02 200.0% 0+0k 0+768io 0pf+0w :ENERGY convergence: 0 0.0001 0 :CHARGE convergence: 0 0. 0 ec cc and fc_conv 0 1 1 cycle 2 (Wed Nov 3 16:29:47 CET 2010) (39/98 to go) lapw0 (16:29:47) 1.2u 0.0s 0:01.27 100.7% 0+0k 0+488io 0pf+0w lapw1 (16:29:49) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+8io 0pf+0w error: command /usr/local/software/install/Wien2K-ifort11.1/lapw1 lapw1.def failed stop error So it starts the first scf step by executing a complex calculation, as it should be for the case where no inversion symmetry is present, but in the second step it calls a real calculation. What files should be corrected in order to fix this bug? Best regards, Marcos -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101103/08943e78/attachment.htm
