[Wien] Error for sphere overlapping
Hello Dear Wien2k usersI am running calculation of minimization on Wien2k_13.01. I faced with error that caused by sphere overlapping due to atomic movement.My structure is LiFePO4 and I chose Rmt as followingLi-0.88Fe-2.0P-1.66O-1.21Then how can i solve this error?Can I decrease these values more? Thanks in advance Regards Tankhilaa___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] initso - convergence jump after reduction of symmetry
Dear prof. Blaha, thank you very much for the fixed symmetso; after running some more tests I am happy to say that the jumps reduced tremendously. Only a small jump now remains, probably connected with the CLM(R) part of density files. Anyway, I believe that now with the new symmetso it will be possible to continue after initso even for more complex structures (e.g., 100+ atoms). If someone is interested the tests are described below. Best regards Vojtech As a test case I used rhombohedral antiferromagnetic FeF3 (SG #148, R-3). Firstl, reproduced the jump with old symmetso using steps: 1) start from converged hisym 2) initso with (3 5 7), leave Emax at 2.5, copy all the *_so files 3) runsp_lapw -p -orb -I -cc 0.1 As expected, large jump occured and subsequently the scf crashed in 4th iteration: :DIS : CHARGE DISTANCE ( 5.5460638 for atom2 spin 2) 3.5299069 :DIS : CHARGE DISTANCE ( 5.4495877 for atom1 spin 2) 5.3681200 :DIS : CHARGE DISTANCE ( 5.3167277 for atom1 spin 2) 5.2076606 Now, using the fixed symmetso and following exactly the same steps produced much smaller jump and converged within a few iterations: :DIS : CHARGE DISTANCE ( 0.0265515 for atom2 spin 1) 0.0348338 :DIS : CHARGE DISTANCE ( 0.0611098 for atom3 spin 2) 0.1550994 :DIS : CHARGE DISTANCE ( 0.0593840 for atom3 spin 2) 0.1500394 :DIS : CHARGE DISTANCE ( 0.1954766 for atom3 spin 2) 0.4753107 :DIS : CHARGE DISTANCE ( 0.2505027 for atom3 spin 2) 0.5898240 :DIS : CHARGE DISTANCE ( 0.1139920 for atom4 spin 1) 0.2875368 :DIS : CHARGE DISTANCE ( 0.0835918 for atom4 spin 1) 0.2053963 :DIS : CHARGE DISTANCE ( 0.0637785 for atom3 spin 2) 0.1722495 :DIS : CHARGE DISTANCE ( 0.0671636 for atom3 spin 2) 0.1724862 :DIS : CHARGE DISTANCE ( 0.0561695 for atom3 spin 2) 0.1454023 :DIS : CHARGE DISTANCE ( 0.0216516 for atom1 spin 2) 0.0290190 :DIS : CHARGE DISTANCE ( 0.0152166 for atom1 spin 2) 0.0160854 :DIS : CHARGE DISTANCE ( 0.0084897 for atom1 spin 2) 0.009 :DIS : CHARGE DISTANCE ( 0.0025667 for atom1 spin 2) 0.0026985 :DIS : CHARGE DISTANCE ( 0.0015687 for atom1 spin 2) 0.0017820 :DIS : CHARGE DISTANCE ( 0.0001951 for atom1 spin 1) 0.0004541 :DIS : CHARGE DISTANCE ( 0.0001265 for atom1 spin 1) 0.0002052 :DIS : CHARGE DISTANCE ( 0.507 for atom1 spin 1) 0.872 :DIS : CHARGE DISTANCE ( 0.190 for atom4 spin 2) 0.436 :DIS : CHARGE DISTANCE ( 0.113 for atom2 spin 2) 0.173 :DIS : CHARGE DISTANCE ( 0.069 for atom1 spin 1) 0.123 I am a Fortran illiterate but as far as I understand this fix in symmetso corrects the plane-waves part of density files, while the CLM(R) parts remain the same. So I tried a few more tests. I converged the structure in low symmetry from scratch in order to obtain CLMs in the final low-symmetry basis. Checked that it reached the same energy as in the original high symmetry: :ENE : ** TOTAL ENERGY IN Ry =-6289.92473283 (hisym) :ENE : ** TOTAL ENERGY IN Ry =-6289.92473386 (lowsym) Then I used the fixed symmetso and on top of it I replaced the CLM(R) of iron atoms (these are the only species where LMs were changed, fluorines are already at lowest symmetry), i.e.: 1) start from converged hisym 2) initso with (3 5 7), leave Emax at 2.5, copy all the *_so files 3) replace CLM(R) of irons with those from well converged "lowsym" calculation. 4) runsp_lapw -p -orb -I -cc 0.1 A further improvement, though small: :DIS : CHARGE DISTANCE ( 0.0265633 for atom1 spin 2) 0.0348425 :DIS : CHARGE DISTANCE ( 0.0579934 for atom3 spin 2) 0.1431763 :DIS : CHARGE DISTANCE ( 0.0583868 for atom3 spin 2) 0.1447817 :DIS : CHARGE DISTANCE ( 0.0700905 for atom1 spin 2) 0.1198294 :DIS : CHARGE DISTANCE ( 0.0697802 for atom1 spin 2) 0.1168461 :DIS : CHARGE DISTANCE ( 0.0299499 for atom1 spin 2) 0.0588715 :DIS : CHARGE DISTANCE ( 0.0243737 for atom4 spin 1) 0.0569459 :DIS : CHARGE DISTANCE ( 0.0147642 for atom3 spin 2) 0.0347052 :DIS : CHARGE DISTANCE ( 0.0146602 for atom3 spin 2) 0.0352172 :DIS : CHARGE DISTANCE ( 0.0149405 for atom3 spin 2) 0.0360313 :DIS : CHARGE DISTANCE ( 0.0044088 for atom3 spin 2) 0.0101669 :DIS : CHARGE DISTANCE ( 0.0023543 for atom5 spin 1) 0.0052931 :DIS : CHARGE DISTANCE ( 0.0012384 for atom4 spin 2) 0.0031746 :DIS : CHARGE DISTANCE ( 0.0003420 for atom3 spin 1) 0
Re: [Wien] How to calculate U for 3d-fully filled
As far as I know, two methods are currently used to calculated U in WIEN2k [ http://www.cms.tuwien.ac.at/media/uploads/cms/psi-presentations/Blaha.ppt (Slide 10) ]: 1) Fitting method: Adjust U until the desired results are obtained (i.e., until the calculated results are matched to the experimental results) http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg12261.html http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg12171.html The U value is usually picked for the fit so that it minimizes the average error among several different properties [ J. Chem. Theory Comput. vol. 7 p. 2218 (2011): http://pubs.acs.org/doi/abs/10.1021/ct200202g ]. 2) Constrained LDA (cLDA) method http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg11746.html http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg08794.html http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07587.html http://arxiv.org/abs/1206.3533v2 It is noted that Ueff values obtained from this method are known to be of questionable accuracy [ JAP vol. 109 p. 063707 (2011): http://dx.doi.org/10.1063/1.3562145 , PRB vol. 76 p. 155123 (2007): http://link.aps.org/doi/10.1103/PhysRevB.76.155123 ]. There is a comparison between different constrained DFT methods in the file at: http://www.fhi-berlin.mpg.de/~xinguo/talks/jiang_cdft-coffeetalk.pdf The linear response method seems to be popular with other DFT software like Quantum-ESPRESSO [ http://hjklol.mit.edu/content/calculating-hubbard-u ]. I hope the references above help and good luck. On 5/27/2015 6:45 AM, Tuan Vu wrote: Dear creators! I have come across a difficulty in realization your program. Can you explain, how to calculate the parameter U for the case, when the d-subshell is completely full filled.(example Zn, Ag or 5d Hg, Tl, Pb) I am grateful to you in advance. Yours sincerely, the third year post-graduate student of Don State Technical University ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Error for sphere overlapping
Yes, you can try decreasing the RMT, where it is recommended to use setrmt (terminal) or "set automatically RMT and continue editing" (w2web) [ http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07996.html , http://www.wien2k.at/reg_user/faq/rmt.html ]. Or you might want to upgrade from WIEN2k 13.1 to 14.2 in order to use reduce_rmt_lapw that was released in WIEN2k 14.1. As it says on the webpage at http://www.wien2k.at/reg_user/updates/ : *reduce_rmt_lapw*: (should be called when a structure optimization stops due to overlapping spheres. It will save the current calc. as case_old_rmt_XX, reduce sphere sizes by a certain amount (3 % or -r XX) and extrapolate densities on the new radial mesh, so that afterwards you can easily continue with the minimization) However, if any of the atomic positions have moved too close to each other, decreasing the RMT might not work and the atomic positions would have to be adjusted so that the atoms do not overlap. Check the failing struct file with xcrysden and/or "x nn", these programs can help you see if the atomic positions are too close. I assume the Li positions are constrained in the calculation as you mentioned before [ http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12403.html ]. I haven't tried constraining positions during optimization. So I don't know, but maybe constraining positions can also lead to such a problem. Also, your RMT of Li looks like it might be too small. From what I have seen in literature, the RMT of Li in LiFePO4 is around 1.97 a.u. [ J. Phys.: Condens. Matter vol. 22 p. 275501 (2010): http://dx.doi.org/10.1088/0953-8984/22/27/275501 ]. On 5/28/2015 4:39 AM, B Tankhilsaihan wrote: Hello Dear Wien2k users I am running calculation of minimization on Wien2k_13.01. I faced with error that caused by sphere overlapping due to atomic movement. My structure is LiFePO4 and I chose Rmt as following Li-0.88 Fe-2.0 P-1.66 O-1.21 Then how can i solve this error? Can I decrease these values more? Thanks in advance Regards Tankhilaa ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
