[Wien] (no subject)
Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/a97ab21a/attachment.htm
[Wien] Problems in convergence due to application of mBj potential
Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/37dbb23f/attachment.htm
[Wien] Virtual-crystal
Dear Users, I am trying to perform a calculation using virtual-crystal method. I have found the way to do this and it is as below. - run through inil_lapw using default atomic numbers - edit nuclear charges in case.struct - edit corresponding occupancies in case.inst - edit the total number of electrons in case.in2 - run SCF circle But I do not understand a few things. First, I do not know how I should change the occupation number. I have looked up the manual, but still confused. Just say that I want to do x = 0.5 for example, then what should I edit? There are numbers like 1.0, 2.0, 3.0 and so on... Second, if I want to add one more electron in the unit cell (two f.u., therefore x = 0.5), should I just do the # of electron + one in case.in2? For example, if the current # of electrons is 25, should I put the # of electrons as 26? All my best, Jihoon Park -- Graduate Research Assistant Magnetic Materials and Device Laboratory Department of Electrical and Computer Engineering 101 Houser Hall, Box 870286 The University of Alabama Tuscaloosa, Alabama 35487 Tel (205)348-3759 Fax (205)348-6959
[Wien] Problems in convergence due to application of mBj potential
It looks as if the mBJ calculation has completely crashed. Constant tests are unusual and point to some other problem which you overlooked. restore_lapw gga_calc runsp -i 1(with GGA) (because you need good vsp and vresp files) change to mBJ in case.in0; rm *.bro* what did you set in case.inm ??? Choose a small (0.03) mixing with PRATT for the first couple of iterations runsp monitor :DIS from the beginning. It should not grow too large and after about 10 cycles a slowly decreasing :DIS must be seen. Then you can probably switch to MSR1a in case.inm Am 22.08.2012 04:48, schrieb Madhav Ghimire: Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at mailto:Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
[Wien] Regarding Rkmax choosing for molecular crystals
Dear Sir, Thank you for reply me. Here, we are using mpi- parallel version. My worry is about Rkmax value. Now i am choosing Rkmax is 2.5 for CHNO compound and i want know the reliability of calculations and effect on band gap using different Rkmaxs. with regards S.Appalakondaiah -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/45ea44d3/attachment.htm
[Wien] Virtual-crystal
x=0.5 of whatever maybe too much for VCA If you change for example the electrons at a transition metal atom, then you should change the number of d electrons in case.inst (they are different for each TM atom, and the occupation of d3/2 and d5/2 depends on kind of atom as well as spin polarised or not). Did you check what numbers change in the input files when you go from x=0.0 to x=1.0 (or from one atom to a neighbouring) ? By the way, if you add 1 electron to Manganese (Z=25) then you have iron (Z=26). To go back to the beginning of the e-mail, VCA does not distinguish the types of atoms, think about whatelse mixtures you model with the same numbers. Is that what you wanted to have ? Ciao Gerhard DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy: I think the problem, to be quite honest with you, is that you have never actually known what the question is. Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Jihoon Park [jpark61 at crimson.ua.edu] Gesendet: Mittwoch, 22. August 2012 06:09 An: wien at zeus.theochem.tuwien.ac.at Betreff: [Wien] Virtual-crystal Dear Users, I am trying to perform a calculation using virtual-crystal method. I have found the way to do this and it is as below. - run through inil_lapw using default atomic numbers - edit nuclear charges in case.struct - edit corresponding occupancies in case.inst - edit the total number of electrons in case.in2 - run SCF circle But I do not understand a few things. First, I do not know how I should change the occupation number. I have looked up the manual, but still confused. Just say that I want to do x = 0.5 for example, then what should I edit? There are numbers like 1.0, 2.0, 3.0 and so on... Second, if I want to add one more electron in the unit cell (two f.u., therefore x = 0.5), should I just do the # of electron + one in case.in2? For example, if the current # of electrons is 25, should I put the # of electrons as 26? All my best, Jihoon Park -- Graduate Research Assistant Magnetic Materials and Device Laboratory Department of Electrical and Computer Engineering 101 Houser Hall, Box 870286 The University of Alabama Tuscaloosa, Alabama 35487 Tel (205)348-3759 Fax (205)348-6959 ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] Virtual-crystal
Does it realy work for atoms from different rows as in the Sr-La example, the total energies should be completely different because of the larger number of core electrons I guess the result is not Sr-La but Sr-Y (or Sr - 1/2 Zr, etc. as the kind of atom is not distinguished). Ciao Gerhard DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy: I think the problem, to be quite honest with you, is that you have never actually known what the question is. Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Peter Blaha [pblaha at theochem.tuwien.ac.at] Gesendet: Mittwoch, 22. August 2012 07:40 An: A Mailing list for WIEN2k users Betreff: Re: [Wien] Virtual-crystal When you increase Z of an atom (with MULT=1) by x, increase also NE in case.in2 by x. Remember: VCA works only for non-active electrons in the valence band (like Sr2+/La3+), but not for active ones (like O/F) Am 22.08.2012 06:09, schrieb Jihoon Park: Dear Users, I am trying to perform a calculation using virtual-crystal method. I have found the way to do this and it is as below. - run through inil_lapw using default atomic numbers - edit nuclear charges in case.struct - edit corresponding occupancies in case.inst - edit the total number of electrons in case.in2 - run SCF circle But I do not understand a few things. First, I do not know how I should change the occupation number. I have looked up the manual, but still confused. Just say that I want to do x = 0.5 for example, then what should I edit? There are numbers like 1.0, 2.0, 3.0 and so on... Second, if I want to add one more electron in the unit cell (two f.u., therefore x = 0.5), should I just do the # of electron + one in case.in2? For example, if the current # of electrons is 25, should I put the # of electrons as 26? All my best, Jihoon Park -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at - ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] Virtual-crystal
Sure. I did not think too much in my answer. What I meant was : use VCA for neighboring atoms in the periodic table, Am 22.08.2012 08:15, schrieb Fecher, Gerhard: Does it realy work for atoms from different rows as in the Sr-La example, the total energies should be completely different because of the larger number of core electrons I guess the result is not Sr-La but Sr-Y (or Sr - 1/2 Zr, etc. as the kind of atom is not distinguished). Ciao Gerhard DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy: I think the problem, to be quite honest with you, is that you have never actually known what the question is. Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Peter Blaha [pblaha at theochem.tuwien.ac.at] Gesendet: Mittwoch, 22. August 2012 07:40 An: A Mailing list for WIEN2k users Betreff: Re: [Wien] Virtual-crystal When you increase Z of an atom (with MULT=1) by x, increase also NE in case.in2 by x. Remember: VCA works only for non-active electrons in the valence band (like Sr2+/La3+), but not for active ones (like O/F) Am 22.08.2012 06:09, schrieb Jihoon Park: Dear Users, I am trying to perform a calculation using virtual-crystal method. I have found the way to do this and it is as below. - run through inil_lapw using default atomic numbers - edit nuclear charges in case.struct - edit corresponding occupancies in case.inst - edit the total number of electrons in case.in2 - run SCF circle But I do not understand a few things. First, I do not know how I should change the occupation number. I have looked up the manual, but still confused. Just say that I want to do x = 0.5 for example, then what should I edit? There are numbers like 1.0, 2.0, 3.0 and so on... Second, if I want to add one more electron in the unit cell (two f.u., therefore x = 0.5), should I just do the # of electron + one in case.in2? For example, if the current # of electrons is 25, should I put the # of electrons as 26? All my best, Jihoon Park -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at - ___ 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 -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ --
[Wien] Regarding Rkmax choosing for molecular crystals
RKMax=2.5 is probably not really enough. But nobody can tell for sure. You have to test it yourself and for that you have to set RKMax=3 and comp?are the results. But check the scf-file, what RKMAX was really used (grep :RKM case.scf). Note: What you put in the input for RKmax cannot always be used and it might be that RKMAX gets automatically reduced (see :WAR) Am 22.08.2012 07:54, schrieb Kondaiah Samudrala: Dear Sir, Thank you for reply me. Here, we are using mpi- parallel version. My worry is about Rkmax value. Now i am choosing Rkmax is 2.5 for CHNO compound and i want know the reliability of calculations and effect on band gap using different Rkmaxs. with regards S.Appalakondaiah ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ --
[Wien] dstart error for a monoclinic lattice (wien2k 9.0 version).
Dear Wien users I am trying to do calculations for monoclinic Zr2Ni7 with the following struct file: CXZ LATTICE,NONEQUIV.ATOMS: 612_B2/m MODE OF CALC=RELA unit=ang 23.041440 8.877937 15.561901 90.00 90.00 95.83 ATOM -1: X=0.6133 Y=0.2115 Z=0. MULT= 2 ISPLIT= 8 -1: X=0.3867 Y=0.7885 Z=0. Zr1NPT= 781 R0=0.0001 RMT=2.4300 Z: 40.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -2: X=0.8840 Y=0.2695 Z=0. MULT= 2 ISPLIT= 8 -2: X=0.1160 Y=0.7305 Z=0. Zr2NPT= 781 R0=0.0005 RMT=2.4300 Z: 40.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -3: X=0.2460 Y=0.2561 Z=0. MULT= 2 ISPLIT= 8 -3: X=0.7540 Y=0.7439 Z=0. Ni1NPT= 781 R0=0.0005 RMT=0.0600 Z: 28.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -4: X=0.0762 Y=0.2075 Z=0.1625 MULT= 4 ISPLIT= 8 -4: X=0.9238 Y=0.7925 Z=0.8375 -4: X=0.9238 Y=0.7925 Z=0.1625 -4: X=0.0762 Y=0.2075 Z=0.8375 Ni2NPT= 781 R0=0.0005 RMT=0.0600 Z: 28.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -5: X=0.4208 Y=0.2974 Z=0.1679 MULT= 4 ISPLIT= 8 -5: X=0.5792 Y=0.7026 Z=0.8321 -5: X=0.5792 Y=0.7026 Z=0.1679 -5: X=0.4208 Y=0.2974 Z=0.8321 Ni3NPT= 781 R0=0.0005 RMT=0.0600 Z: 28.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -6: X=0.2507 Y=0.5033 Z=0.2464 MULT= 4 ISPLIT= 8 -6: X=0.7493 Y=0.4967 Z=0.7536 -6: X=0.7493 Y=0.4967 Z=0.2464 -6: X=0.2507 Y=0.5033 Z=0.7536 Ni4NPT= 781 R0=0.0005 RMT=0.0600 Z: 28.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 4 NUMBER OF SYMMETRY OPERATIONS -1 0 0 0. 0-1 0 0. 0 0-1 0. 1 -1 0 0 0. 0-1 0 0. 0 0 1 0. 2 1 0 0 0. 0 1 0 0. 0 0-1 0. 3 1 0 0 0. 0 1 0 0. 0 0 1 0. 4 I am getting the following error in dstart. Commandline: x dstart Program input is: forrtl: severe (24): end-of-file during read, unit 81, file /home/sanjeev/Wien_Computes/Zr2Ni7_1/Zr2Ni7_1.rsp Image PCRoutineLineSource dstart 004B6F1D Unknown Unknown Unknown dstart 004B5A25 Unknown Unknown Unknown dstart 004657B9 Unknown Unknown Unknown dstart 0043136D Unknown Unknown Unknown dstart 00430BBA Unknown Unknown Unknown dstart 0044291D Unknown Unknown Unknown dstart 0040F1D5 init_ 91 init.f dstart 0040DF3D MAIN__ 9 dstart.f dstart 004032EC Unknown Unknown Unknown libc.so.6 003343E1EA4D Unknown Unknown Unknown dstart 004031E9 Unknown Unknown Unknown 0.001u 0.002s 0:00.00 0.0% 0+0k 0+16io 0pf+0w error: command /usr/local/Wien2K/dstart dstart.def failed Pl. help in overcoming this problem. Best regards Sanjeev -- Dr. Sanjeev Kumar Srivastava Assistant Professor Department of Physics Indian Institute of Technology Kharagpur Kharagpur 721302 India Ph.: 0091-3222-283854 (Office) 0091-3222-283855 (Residence) Mobile: 0091-9735444091 ---
[Wien] dstart error for a monoclinic lattice (wien2k 9.0 version).
You cannot make a calculation with RMT=0.06 bohr for Ni ? I am trying to do calculations for monoclinic Zr2Ni7 with the following struct file: CXZ LATTICE,NONEQUIV.ATOMS: 612_B2/m MODE OF CALC=RELA unit=ang 23.041440 8.877937 15.561901 90.00 90.00 95.83 ATOM -1: X=0.6133 Y=0.2115 Z=0. MULT= 2 ISPLIT= 8 -1: X=0.3867 Y=0.7885 Z=0. Zr1NPT= 781 R0=0.0001 RMT=2.4300 Z: 40.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -2: X=0.8840 Y=0.2695 Z=0. MULT= 2 ISPLIT= 8 -2: X=0.1160 Y=0.7305 Z=0. Zr2NPT= 781 R0=0.0005 RMT=2.4300 Z: 40.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -3: X=0.2460 Y=0.2561 Z=0. MULT= 2 ISPLIT= 8 -3: X=0.7540 Y=0.7439 Z=0. Ni1NPT= 781 R0=0.0005 RMT=0.0600 Z: 28.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ --
[Wien] dstart error for a monoclinic lattice (wien2k 9.0 version).
Dear Prof. Blaha Thanks for identifying the silly mistake!!! Regards Sanjeev - Original Message - From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, August 22, 2012 4:30:16 PM Subject: Re: [Wien] dstart error for a monoclinic lattice (wien2k 9.0 version). You cannot make a calculation with RMT=0.06 bohr for Ni ? I am trying to do calculations for monoclinic Zr2Ni7 with the following struct file: CXZ LATTICE,NONEQUIV.ATOMS: 612_B2/m MODE OF CALC=RELA unit=ang 23.041440 8.877937 15.561901 90.00 90.00 95.83 ATOM -1: X=0.6133 Y=0.2115 Z=0. MULT= 2 ISPLIT= 8 -1: X=0.3867 Y=0.7885 Z=0. Zr1NPT= 781 R0=0.0001 RMT=2.4300 Z: 40.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -2: X=0.8840 Y=0.2695 Z=0. MULT= 2 ISPLIT= 8 -2: X=0.1160 Y=0.7305 Z=0. Zr2NPT= 781 R0=0.0005 RMT=2.4300 Z: 40.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -3: X=0.2460 Y=0.2561 Z=0. MULT= 2 ISPLIT= 8 -3: X=0.7540 Y=0.7439 Z=0. Ni1NPT= 781 R0=0.0005 RMT=0.0600 Z: 28.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 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 -- Dr. Sanjeev Kumar Srivastava Assistant Professor Department of Physics Indian Institute of Technology Kharagpur Kharagpur 721302 India Ph.: 0091-3222-283854 (Office) 0091-3222-283855 (Residence) Mobile: 0091-9735444091 ---
[Wien] Problems in convergence due to application of mBj potential
Can you send the case.scf file to me directly? I am curious why MSR1 does not converge well for some mBJ and there are some things printed in case.scfm which may explain. --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On Aug 21, 2012 9:50 PM, Madhav Ghimire ghimire.mpg at gmail.com wrote: Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/415df266/attachment.htm
[Wien] Problems in convergence due to application of mBj potential
Dear Prof. Blaha, I have changed the PRATT with a mixing factor between 0.2-0.5 in case.inm not as small as you suggest. Thanks for this new information. I will try the suggested value and see what happens. Thanks Madhav On Wed, Aug 22, 2012 at 2:37 PM, Peter Blaha pblaha at theochem.tuwien.ac.atwrote: It looks as if the mBJ calculation has completely crashed. Constant tests are unusual and point to some other problem which you overlooked. restore_lapw gga_calc runsp -i 1(with GGA) (because you need good vsp and vresp files) change to mBJ in case.in0; rm *.bro* what did you set in case.inm ??? Choose a small (0.03) mixing with PRATT for the first couple of iterations runsp monitor :DIS from the beginning. It should not grow too large and after about 10 cycles a slowly decreasing :DIS must be seen. Then you can probably switch to MSR1a in case.inm Am 22.08.2012 04:48, schrieb Madhav Ghimire: Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.atmailto: Wien at zeus.theochem.**tuwien.ac.at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- --**--- Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at --**--- __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/adbc2481/attachment.htm
[Wien] Problems in convergence due to application of mBj potential
-- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/bf198419/attachment.htm
[Wien] Problems in convergence due to application of mBj potential
Dear Prof. Marks, Thank you very much for replying immediately. I was just replying to your post. As in userguide of wien2k, it is suggested to edit the case.inm and change MSR1a with PRATT as MSR1a leads to convergence problems in mBj. Hence, I performed the calculations by changing MSR1a with PRATT. I will follow to what you suggest right now and report within a day or two. Please let me know more if I have to be cautious somewhere in the calculations. Thanks. Madhav On Wed, Aug 22, 2012 at 8:21 PM, Laurence Marks L-marks at northwestern.eduwrote: Can you send the case.scf file to me directly? I am curious why MSR1 does not converge well for some mBJ and there are some things printed in case.scfm which may explain. --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On Aug 21, 2012 9:50 PM, Madhav Ghimire ghimire.mpg at gmail.com wrote: Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/8c470da4/attachment.htm
[Wien] Problems in convergence due to application of mBj potential
I am sure Peter had a typo - I think he meant MSR1 not MSR1a. Whether MSR1a is a good idea with mBJ is currently unclear; there was a recent discussion of this, look in the email archives. A good topic where readers of this list could contribute is testing whether MSR1a with mBJ is physically reasonable and reporting back. On Aug 22, 2012 8:47 AM, Madhav Ghimire ghimire.mpg at gmail.com wrote: Dear Prof. Marks, Thank you very much for replying immediately. I was just replying to your post. As in userguide of wien2k, it is suggested to edit the case.inm and change MSR1a with PRATT as MSR1a leads to convergence problems in mBj. Hence, I performed the calculations by changing MSR1a with PRATT. I will follow to what you suggest right now and report within a day or two. Please let me know more if I have to be cautious somewhere in the calculations. Thanks. Madhav On Wed, Aug 22, 2012 at 8:21 PM, Laurence Marks L-marks at northwestern.eduwrote: Can you send the case.scf file to me directly? I am curious why MSR1 does not converge well for some mBJ and there are some things printed in case.scfm which may explain. --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On Aug 21, 2012 9:50 PM, Madhav Ghimire ghimire.mpg at gmail.com wrote: Dear wien users and developers, I am working on some 3d TM oxides. With a normal scf cycle with or without inclusion of U value, I got good convergence in energy and charge. This oxide material is reported to have a bandgap of approx. 0.3 eV. In GGA, I do not observe any gap. In the meantime even with very high value of U, the bandgap do not open up. Because of this, I tried to implement mBj potential (in order to find the bandgap) both with and without inclusion of U, but the energy and charge do not converge. Rather even for a large number of iteration (199), the energy and charge remains constant without convergence (shown below). For GGA without mBj the scf cycle smoothly converges as below: in cycle 22ETEST: .23685000 CTEST: .0038743 in cycle 23ETEST: .1843 CTEST: .0012996 in cycle 24ETEST: .17465000 CTEST: .0006011 in cycle 25ETEST: .0376 CTEST: .0007451 in cycle 26ETEST: .01605000 CTEST: .0001163 stop while with mBj+GGA, energy and charge convergence remains constant above cycle 103 and could not converge as below: in cycle 193ETEST: .211210395000 CTEST: 2.0591251 in cycle 194ETEST: .211210395000 CTEST: 2.0591251 in cycle 195ETEST: .211210395000 CTEST: 2.0591251 in cycle 196ETEST: .211210395000 CTEST: 2.0591251 in cycle 197ETEST: .211210395000 CTEST: 2.0591251 in cycle 198ETEST: .211210395000 CTEST: 2.0591251 in cycle 199ETEST: .211210395000 CTEST: 2.0591251 energy in SCF NOT CONVERGED Does anyone have experienced this type of problems. If so, please let me know how it can be converged. I followed all the steps as described in previous wien mail and userguid but could not solve. Your help to solve this issue will be higly appreciated. Thanks in advance Madhav Ghimire -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- MANA, National Institute for Materials Science (NIMS) 1-1 Namiki, Tsukuba, Ibaraki, Japan Phone: +81-29-851-3354 (ex.4115) -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120822/edba82f8/attachment.htm
[Wien] reg: dHvA affect
Dear Swetarekha Ram, Because you selected Maximum distance (fraction of RUC side length) between average coordinates for orbit averaging: 0.05 for default = 5% of RUC side lengths, the multiple copies you found are probably different versions of the same orbit located in different parts of the Reciprocal Unit Cell (RUC). If this is the case, looking in the results_short.out file should reveal that the different copies have different listed RUC avg coords (by at least 5%). If you don't care about the location of the orbits, you can just set Maximum distance (fraction of RUC side length) between average coordinates for orbit averaging to 1, so that it will average together orbits from anywhere in the RUC (as long as they satisfy the Maximum fractional diff. between orbit freqs. for averaging criterion). A few other suggestions: - As Jianxin Zhu mentioned, make sure you are using the latest version of SKEAF (1.3.0 r149), since it has some important improvements and bug fixes. - The README-forSKEAF.txt file included with the SKEAF package may help to explain some details further, especially the 4. PROGRAM USAGE and 5. CHECKING OUTPUT sections. Best regards, Patrick Rourke Message: 4 Date: Sun, 19 Aug 2012 19:15:34 +0530 From: Swetarekha Ram swetarekharam at gmail.com Subject: [Wien] reg: dHvA To: wien-owner at zeus.theochem.tuwien.ac.at, wien at zeus.theochem.tuwien.ac.at Message-ID: CAFsnUVba9CZJv=VooXqoQ53RL5HGoK2mktWB-A0Q3m=FVoRYyA at mail.gmail.com Content-Type: text/plain; charset=windows-1252 Dear WIEN2k users, I am trying to use the SKEAF programme to calculate the de Haas?van Alphen frequencies from the band energy. I tried to explore the dHvA frequency. But I have some doubt. My system is cubic system. What actually I did: 1.Reading data from the bxsf file. 2. Number of interpolated k-points per single new cell side : 100 3. H-vector: a 4. Minimum allowed extremal Fermi surface : 0 (to allow all extremal frequencies) 5. set the parameters used for determining which orbits are multiple copies of one another and therefore should be averaged together: 0.01 (for default = 1%) 6. Maximum distance (fraction of RUC side length) between average coordinates for orbit averaging: 0.05 for default = 5% of RUC side lengths 7. Allow extremal orbits located near super-cell walls: n (no) After this I got the output as below : But I did not understand why it is repeating the results, and what is my actual frequency ? Can any one explain more details about this ? Previously I sent the same but I did not get any reply still. This time I am expecting some response. Thanking you -- Swetarekha Ram, Research Scholar, Dept. of Physics, IIT Hyderabad. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120819/1fc1cae4/attachment-0001.htm -- Message: 5 Date: Sun, 19 Aug 2012 19:26:07 +0530 From: Swetarekha Ram swetarekharam at gmail.com Subject: [Wien] reg: dHvA affect To: wien at zeus.theochem.tuwien.ac.at Message-ID: CAFsnUVY_E7MZZYZ902b1JtHNGx63stQowrop=-_EV_XdYUY2cw at mail.gmail.com Content-Type: text/plain; charset=windows-1252 Dear WIEN2k users, I am trying to use the SKEAF programme to calculate the de Haas?van Alphen frequencies from the band energy. I tried to explore the dHvA frequency. But I have some doubt. My system is cubic system. What actually I did: 1.Reading data from the bxsf file. 2. Number of interpolated k-points per single new cell side : 100 3. H-vector: a 4. Minimum allowed extremal Fermi surface : 0 (to allow all extremal frequencies) 5. set the parameters used for determining which orbits are multiple copies of one another and therefore should be averaged together: 0.01 (for default = 1%) 6. Maximum distance (fraction of RUC side length) between average coordinates for orbit averaging: 0.05 for default = 5% of RUC side lengths 7. Allow extremal orbits located near super-cell walls: n (no) After this I got the output as below : But I did not understand why it is repeating the results, and what is my actual frequency ? Theta(deg),Phi(deg),Freq(kT),mstar(me),Curv(kTA2),Type(+e-h),NumOrbCopy 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00, 8.106024E-02, 2.695113E-01, 2.948198E+01,-1.000, 48 0.00, 90.00,
[Wien] LDA+U: around mean field
Dear Wien2k experts, should one use Ueff=U-J, J=0 also in the 'around mean field' DC correction scheme (option 0 in case.inorb)? Thanks! Kateryna Foyevtsova
[Wien] resolution dependent F(HKL)s from lapw3
Dear WIEN users, I noticed a strange behavior of lapw3 which I do not understand: Take for example a simple diamond case and calculate structure factors from clmsum, lets say up to sin theta/lambda = 1.0: 000 0.000 12.251726 -1 -1 -1 0.2427814 -4.6536716863 00 -2 0.28033980.00 0 -2 -2 0.3964603 -3.9459734623 -1 -1 -3 0.4648909 -2.3988162763 -2 -2 -2 0.48556270.2266152403 00 -4 0.5606796 -3.1297582248 -1 -3 -3 0.61098642.2069300710 0 -2 -4 0.62685880.00 -2 -2 -4 0.68668942.8777607788 -3 -3 -3 0.72834411.9393120414 -1 -1 -5 0.72834411.9663566686 0 -4 -4 0.79292062.6458269883 -1 -3 -5 0.82925621.8056937118 -2 -4 -4 0.8410193 -0.0171687161 00 -6 0.84101930.00 0 -2 -6 0.88651222.4363270068 -3 -3 -5 0.9191554 -1.6841664183 -2 -2 -6 0.9297818 -0.0087306004 -4 -4 -4 0.9711255 -2.2589221048 Repeating this calculation with sin theta/lambda = 1.1 and a diff with the old hkl will just show the additional reflections as expected: diff hkl.10 hkl.11 20a21,26 -1 -5 -5 1.00101321.6970975057 -1 -1 -7 1.00101321.5391902602 0 -4 -6 1.01077940.00 -2 -4 -6 1.0489354 -2.0944311378 -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 Now again repeat the calculation with sin theta/lambda = 1.2: diff hkl.11 hkl.12 25,26c25,32 -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 --- -3 -5 -5 1.0766653 -1.4106390375 -1 -3 -7 1.0766653 -1.4699320085 00 -8 1.12135911.9443586030 -3 -3 -7 1.14734001.3618747163 -4 -4 -6 1.15587050.0030399053 0 -2 -8 1.15587050.00 0 -6 -6 1.18938091.7411783356 -2 -2 -8 1.1893809 -1.8133181764 What happens here? Why are reflections which were exactly the same before suddenly different? Why I worry about this is, that if you go on increasing the resolution, the differences become more severe than in the example above, i.e. sin theta/lambda = 1.3: diff hkl.12 hkl.13 21,22c21,22 -1 -5 -5 1.00101321.6970975057 -1 -1 -7 1.00101321.5391902602 --- -1 -5 -5 1.0010132 -1.5542465484 -1 -1 -7 1.00101321.5480881986 On the other hand, the differences converge for a given reflection but more and more become affected, i.e. sin theta/lambda = 1.8 vs. 1.2: diff hkl.12 hkl.18 21,22c21,22 -1 -5 -5 1.00101321.6970975057 -1 -1 -7 1.00101321.5391902602 --- -1 -5 -5 1.0010132 -1.5542465484 -1 -1 -7 1.00101321.5480881986 25,26c25,26 -3 -5 -5 1.0766653 -1.4106390375 -1 -3 -7 1.0766653 -1.4699320085 --- -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 28c28 -3 -3 -7 1.14734001.3618747163 --- -3 -3 -7 1.1473400 -1.3370357923 31c31 0 -6 -6 1.18938091.7411783356 --- 0 -6 -6 1.1893809 -1.8136982305 Looking at the result of a refinement of a structural model against the different HKLs, the high resolution version seems to be wrong compared to the low-res one. Thank you very much in advance for any comments on this. regards Georg Eickerling -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3362 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
[Wien] resolution dependent F(HKL)s from lapw3
Peter can/will probably make some comments. From what I can remember, lapw3 is an old, not completely optimized code. If you dig through it (which you may have to do for what you appear to want) you will find it does a convolution to correct the PW's so they are zero within the spheres, and a numerical transform for the density within the spheres. Both are probably going to depend upon the sampling (largest HKL used) and for certain you will need a large RKMAX and GMAX as otherwise the PW's will be truncated (inspect case.clmsum -- are the high angle values you want there?) The main use of lapw3 in the past has been for the lower-angle values that are affected by bonding and these are OK although there are some issues (dig into the literature on charge density comparisons) particularly at high angles which have to do with how the core states are calculated. Search for charge density on the Wien2k publications page. On Wed, Aug 22, 2012 at 11:32 AM, Georg Eickerling georg.eickerling at physik.uni-augsburg.de wrote: Dear WIEN users, I noticed a strange behavior of lapw3 which I do not understand: Take for example a simple diamond case and calculate structure factors from clmsum, lets say up to sin theta/lambda = 1.0: 000 0.000 12.251726 -1 -1 -1 0.2427814 -4.6536716863 00 -2 0.28033980.00 0 -2 -2 0.3964603 -3.9459734623 -1 -1 -3 0.4648909 -2.3988162763 -2 -2 -2 0.48556270.2266152403 00 -4 0.5606796 -3.1297582248 -1 -3 -3 0.61098642.2069300710 0 -2 -4 0.62685880.00 -2 -2 -4 0.68668942.8777607788 -3 -3 -3 0.72834411.9393120414 -1 -1 -5 0.72834411.9663566686 0 -4 -4 0.79292062.6458269883 -1 -3 -5 0.82925621.8056937118 -2 -4 -4 0.8410193 -0.0171687161 00 -6 0.84101930.00 0 -2 -6 0.88651222.4363270068 -3 -3 -5 0.9191554 -1.6841664183 -2 -2 -6 0.9297818 -0.0087306004 -4 -4 -4 0.9711255 -2.2589221048 Repeating this calculation with sin theta/lambda = 1.1 and a diff with the old hkl will just show the additional reflections as expected: diff hkl.10 hkl.11 20a21,26 -1 -5 -5 1.00101321.6970975057 -1 -1 -7 1.00101321.5391902602 0 -4 -6 1.01077940.00 -2 -4 -6 1.0489354 -2.0944311378 -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 Now again repeat the calculation with sin theta/lambda = 1.2: diff hkl.11 hkl.12 25,26c25,32 -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 --- -3 -5 -5 1.0766653 -1.4106390375 -1 -3 -7 1.0766653 -1.4699320085 00 -8 1.12135911.9443586030 -3 -3 -7 1.14734001.3618747163 -4 -4 -6 1.15587050.0030399053 0 -2 -8 1.15587050.00 0 -6 -6 1.18938091.7411783356 -2 -2 -8 1.1893809 -1.8133181764 What happens here? Why are reflections which were exactly the same before suddenly different? Why I worry about this is, that if you go on increasing the resolution, the differences become more severe than in the example above, i.e. sin theta/lambda = 1.3: diff hkl.12 hkl.13 21,22c21,22 -1 -5 -5 1.00101321.6970975057 -1 -1 -7 1.00101321.5391902602 --- -1 -5 -5 1.0010132 -1.5542465484 -1 -1 -7 1.00101321.5480881986 On the other hand, the differences converge for a given reflection but more and more become affected, i.e. sin theta/lambda = 1.8 vs. 1.2: diff hkl.12 hkl.18 21,22c21,22 -1 -5 -5 1.00101321.6970975057 -1 -1 -7 1.00101321.5391902602 --- -1 -5 -5 1.0010132 -1.5542465484 -1 -1 -7 1.00101321.5480881986 25,26c25,26 -3 -5 -5 1.0766653 -1.4106390375 -1 -3 -7 1.0766653 -1.4699320085 --- -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 28c28 -3 -3 -7 1.14734001.3618747163 --- -3 -3 -7 1.1473400 -1.3370357923 31c31 0 -6 -6 1.18938091.7411783356 --- 0 -6 -6 1.1893809 -1.8136982305 Looking at the result of a refinement of a structural model against the different HKLs, the high resolution version seems to be wrong compared to the low-res one. Thank you very much in advance for any comments on this. regards Georg Eickerling -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik
