Re: [Wien] wien2wannier interfaced with wien2k 17.1
Hi Oleg, I don't understand why in GaAs including spin-orbit coupling would induce such big changes in the MLWFs. But anyway, it is probably what it is. My purpose is to extract some Kondo coupling parameters between the Ce 4f and 5d states. In my case, it may be important to generate atomic-orbital like WFs. I am not sure whether I should include 4f WFs or not. I am still playing with it. Best, Jianpeng On Mon, Sep 25, 2017 at 4:12 PM, Rubel, Oleg wrote: > Hello Jianpeng, > > > As to difference between the Wannier centers with and without SOC: did > you carry out maximal localization procedure in both cases (with and > without SOC)? > > Yes, I did optimization in both cases. > > > What if you simply do a single-step projection, i.e., set num_iter=0 ? > > I do not think you will get MLWF in this case since the purpose of > iterations is to achieve a max localization. > > > Then the projected localized functions will not hybridize with each > other, and should have the symmetry of atomic orbitals (as long as these > initial projections are well localized after some disentanglement > procedure). > > GaAs is easy since there is no need for disentanglement. > > > As to the meaning of the tight-binding model: I think it is meaningful > as long as the low-energy bandstructure is the same as the DFT > bandstructure and the Wannier functions are well localized. But I agree it > may be more convenient in some cases if the Wannier functions are > atomic-orbital like. > > If you only need to fit the band structure, the it is OK to have WF > shifted. But usually the objective is beyond that. What would you like to > do with WF after wannierization? > > > Thank you > Oleg > > ___ > 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/wi > e...@zeus.theochem.tuwien.ac.at/index.html > ___ 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] wien2wannier interfaced with wien2k 17.1
Hi Oleg, Thanks for testing the procedures on GaAs. As to difference between the Wannier centers with and without SOC: did you carry out maximal localization procedure in both cases (with and without SOC)? What if you simply do a single-step projection, i.e., set num_iter=0 ? Then the projected localized functions will not hybridize with each other, and should have the symmetry of atomic orbitals (as long as these initial projections are well localized after some disentanglement procedure). As to the meaning of the tight-binding model: I think it is meaningful as long as the low-energy bandstructure is the same as the DFT bandstructure and the Wannier functions are well localized. But I agree it may be more convenient in some cases if the Wannier functions are atomic-orbital like. Thanks! Jianpeng On Mon, Sep 25, 2017 at 12:49 PM, Rubel, Oleg wrote: > Dear Jianpeng: > > I applied your procedure to WF in zinc-blende GaAs. Your procedure works. > I had to do two extra steps > $ cp wannier.inwf wannier.inwfup > $ cp wannier.inwf wannier.inwfdn > before running > $ x w2w -so -up > $ x w2w -so -dn > > The projections are: > begin projections > 1:sp3(u,d) > 2:sp3(u,d) > end projections > > At the end I got the following output with -so and -sp options: > > Final State > WF centre and spread1 ( -0.457506, 0.457588, 0.457476 ) > 4.36038947 > WF centre and spread2 ( 0.457535, 0.457378, -0.457522 ) > 4.36341214 > WF centre and spread3 ( -0.457477, -0.457464, -0.457434 ) > 4.36424964 > WF centre and spread4 ( 0.457409, -0.457465, 0.457515 ) > 4.36405300 > WF centre and spread5 ( 1.800179, -1.026445, -1.026433 ) > 2.89020535 > WF centre and spread6 ( 1.800146, -1.800199, -1.800158 ) > 2.89044140 > WF centre and spread7 ( 1.026459, -1.026417, -1.800189 ) > 2.88989157 > WF centre and spread8 ( 1.026408, -1.800139, -1.026430 ) > 2.89026491 > WF centre and spread9 ( -0.457482, 0.457621, 0.457463 ) > 4.36089512 > WF centre and spread 10 ( 0.457601, 0.457520, -0.457595 ) > 4.35805760 > WF centre and spread 11 ( -0.457628, -0.457579, -0.457578 ) > 4.35685014 > WF centre and spread 12 ( 0.457550, -0.457579, 0.457661 ) > 4.35678662 > WF centre and spread 13 ( 1.800180, -1.026454, -1.026421 ) > 2.89005317 > WF centre and spread 14 ( 1.800147, -1.800197, -1.800166 ) > 2.88979441 > WF centre and spread 15 ( 1.026464, -1.026412, -1.800185 ) > 2.89031329 > WF centre and spread 16 ( 1.026412, -1.800135, -1.026420 ) > 2.88997190 > Sum of centres and spreads ( 11.306397,-11.306377,-11.306414 ) > 58.00562975 > > It can be compared to the calculation without -so and -sp > > Final State > WF centre and spread1 ( -0.00, 0.00, -0.00 ) > 1.91775879 > WF centre and spread2 ( 0.00, -0.00, 0.00 ) > 5.85946098 > WF centre and spread3 ( -0.00, -0.00, -0.00 ) > 5.85946098 > WF centre and spread4 ( 0.00, 0.00, 0.00 ) > 5.85946098 > WF centre and spread5 ( 1.413300, -1.413300, -1.413300 ) > 1.61203280 > WF centre and spread6 ( 1.413300, -1.413300, -1.413300 ) > 3.81968345 > WF centre and spread7 ( 1.413300, -1.413300, -1.413300 ) > 3.81968345 > WF centre and spread8 ( 1.413300, -1.413300, -1.413300 ) > 3.81968345 > Sum of centres and spreads ( 5.653200, -5.653200, -5.653200 ) > 32.56722487 > > It looks like Wannier centres with SOC are not centred at atomic > positions, which implies that their interpretation as atomic orbitals will > be a stretch. I am not sure how useful the Hamiltonian will be then. > > > Thank you > Oleg > -- > Oleg Rubel (PhD, PEng) > Department of Materials Science and Engineering > McMaster University > JHE 359, 1280 Main Street West, Hamilton, Ontario L8S 4L8, Canada > Email: rub...@mcmaster.ca > Tel: +1-905-525-9140, ext. 24094 > Web: http://olegrubel.mcmaster.ca > > > On Sep 25, 2017, at 10:52, Jianpeng Liu wrote: > > > > Dear WIEN2k users and developers, > > > > I am using wien2wannier to generate a tight-binding model for some > rare-earth compound including Ce. Both spin-orbit coupling and > spin-polarization have been included in my calculation. The following is my > workflow: > > > > 1) Finish a scf calculation, then prepare_w2wdir wannier > > > > 2) init_w2w -up > > At this step, I have to specify the energy windows. > > > > 3) write_inwf -f wannier > > At this step, I have to input the minimal and maximal band indices > exported from t
[Wien] wien2wannier interfaced with wien2k 17.1
Dear WIEN2k users and developers, I am using wien2wannier to generate a tight-binding model for some rare-earth compound including Ce. Both spin-orbit coupling and spin-polarization have been included in my calculation. The following is my workflow: 1) Finish a scf calculation, then prepare_w2wdir wannier 2) init_w2w -up At this step, I have to specify the energy windows. 3) write_inwf -f wannier At this step, I have to input the minimal and maximal band indices exported from the previous step, then specify the projections of the Wannier functions. I want to project onto 5 Ce d orbitals, but I made two identical copies of projections, i.e.: Ce:d Ce:d One for spin-up, and the other for spin-dn, so in total there are 10 projections. I copied the generated file wannier.inwf to wannier.inwfup and wannier.inwfdn. Now both wannier.inwfup and .inwfdn have 10 projections, but actually there are only 5 orbitals without the spin degrees of freedom. Did I do it correctly? 4) Then I wrote a wannier.win file by myself, in which there are 10 *spinor* Wannier-function projections, and I set spinors=.true. (is this correct?). 5)With all the inputs generated from the previous steps, I re-run the lapw1 calculation on the full BZ mesh, run wannier90 -pp to generate .nnkp file, run w2w, and then finally wannier90: x lapw1 -up -p x lapw1 -dn -p x lapwso -up -p x wannier90 -pp x w2w -so -up -p x w2w -so -dn -p x wannier90 -so The above is my workflow of wien2wannier. The code seems to be running well, but I am not sure if I did everything correctly. In particular I am worried that there are 2 identical copies of the orbital projections in both wannier.inwfup and .inwfdn. I would like to make sure that it is correct. I would greatly appreciate your help. Best, Jianpeng ___ 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 in WIENNCM running in parallel mode
Dear Gavin, Thank you for the helpful link! I think that's the bug! Indeed I have fixed a bug of wienncm by modifying the lines related to block size in zhcgst.f (SRC_lapw1), but here is one more... It seems to me WIENncm is really out-of-dated, and there are quite a few bugs to be fixed. I am using it because I thought it allows one to couple external magnetic field to orbital magnetic moments by adding orbital potentials, so I want to make sure here: Is it true that WIENncm allows the coupling between external magnetic field and the *orbital* magnetic moment? And one more question, for body-centered tetragonal system, is it possible to plot Fermi-surface? Since WIENncm is too old, I can not assume that it has the features of the latest WIEN2k. If it doesn't do these things, then I will switch to some other codes. Thanks again for the help. Jianpeng On Thu, Sep 7, 2017 at 11:00 PM, Jianpeng Liu wrote: > Dear Gavin, > > Thank you for your prompt replay. I have checked that energy_1 has been > properly generated. The lapw2.error says: > 'FERMI' - number of k-points inconsistent when reading kgen > 'FERMI' - check IN1 and KGEN files! > > I have generated the k mesh using initncm, and set the total number of k > points in BZ as 216 (the system is body-centered tetragonal, and there is > no symmetry of the magnetic state, so there is also 216 k points in the > irreducible BZ). I set up the .machines file to divide the 216 points to 12 > processors, 18 k points for each processor. Then there is the problem: > there are 18 k points in case.klist_1 ... case.klist_11, but in > case.klist_12, there are only 16 k points, i.e., 2 kpoints are just > missing. This is probably why the system complains with the k point error? > > Later I tried to change the method of determining the Fermi level from the > linear-tetrahedra method to Gaussian smearing, with eval=0.0005Ry, then > everything works. Still, two k points are missing in case.klist_12, but now > the calculation runs well with 12 processors. Can I ask why the linear > tetrahedra method fails, and why the two k points are missing? > > Best, > Jianpeng > > > > On Thu, Sep 7, 2017 at 9:17 PM, Gavin Abo wrote: > >> You might try checking the lapw2.error file. Does it show a problem with >> the case.energy_1 file like in the post at: >> >> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at >> /msg07963.html >> >> If you have that same error, it might be that lapw1 failed in generating >> the case.energy_1. There are other files you may need to look for error >> messages in as mentioned before in the mailing list archive [ >> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at >> /msg15549.html ]. >> >> >> On 9/7/2017 5:32 PM, Jianpeng Liu wrote: >> >> Dear Wien2k/Wienncm users and developers, >> >> I am learning to use wienncm to run some noncollinear-magnetism >> calculations. I have compiled the code without any error report, and the >> code runs well in serial mode. But if I run the same calculation in >> parallel mode, the calculation is always aborted at the lapw2 step, and I >> got the following error: >> >> FERMI - Error >> cp: cannot stat `.in.tmp': No such file or directory >> rm: cannot remove `.in.tmp': No such file or directory >> rm: cannot remove `.in.tmp1': No such file or directory >> >> The following is the .machine file: >> >> granularity:1 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> 1:node91 >> >> I would appreciate your help. >> >> Best, >> Jianpeng >> >> >> ___ >> 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/wi >> e...@zeus.theochem.tuwien.ac.at/index.html >> >> > ___ 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 in WIENNCM running in parallel mode
Dear Gavin, Thank you for your prompt replay. I have checked that energy_1 has been properly generated. The lapw2.error says: 'FERMI' - number of k-points inconsistent when reading kgen 'FERMI' - check IN1 and KGEN files! I have generated the k mesh using initncm, and set the total number of k points in BZ as 216 (the system is body-centered tetragonal, and there is no symmetry of the magnetic state, so there is also 216 k points in the irreducible BZ). I set up the .machines file to divide the 216 points to 12 processors, 18 k points for each processor. Then there is the problem: there are 18 k points in case.klist_1 ... case.klist_11, but in case.klist_12, there are only 16 k points, i.e., 2 kpoints are just missing. This is probably why the system complains with the k point error? Later I tried to change the method of determining the Fermi level from the linear-tetrahedra method to Gaussian smearing, with eval=0.0005Ry, then everything works. Still, two k points are missing in case.klist_12, but now the calculation runs well with 12 processors. Can I ask why the linear tetrahedra method fails, and why the two k points are missing? Best, Jianpeng On Thu, Sep 7, 2017 at 9:17 PM, Gavin Abo wrote: > You might try checking the lapw2.error file. Does it show a problem with > the case.energy_1 file like in the post at: > > https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07963.html > > If you have that same error, it might be that lapw1 failed in generating > the case.energy_1. There are other files you may need to look for error > messages in as mentioned before in the mailing list archive [ > https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15549.html > ]. > > > On 9/7/2017 5:32 PM, Jianpeng Liu wrote: > > Dear Wien2k/Wienncm users and developers, > > I am learning to use wienncm to run some noncollinear-magnetism > calculations. I have compiled the code without any error report, and the > code runs well in serial mode. But if I run the same calculation in > parallel mode, the calculation is always aborted at the lapw2 step, and I > got the following error: > > FERMI - Error > cp: cannot stat `.in.tmp': No such file or directory > rm: cannot remove `.in.tmp': No such file or directory > rm: cannot remove `.in.tmp1': No such file or directory > > The following is the .machine file: > > granularity:1 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > 1:node91 > > I would appreciate your help. > > Best, > Jianpeng > > > ___ > 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 > > ___ 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
[Wien] Error in WIENNCM running in parallel mode
Dear Wien2k/Wienncm users and developers, I am learning to use wienncm to run some noncollinear-magnetism calculations. I have compiled the code without any error report, and the code runs well in serial mode. But if I run the same calculation in parallel mode, the calculation is always aborted at the lapw2 step, and I got the following error: FERMI - Error cp: cannot stat `.in.tmp': No such file or directory rm: cannot remove `.in.tmp': No such file or directory rm: cannot remove `.in.tmp1': No such file or directory The following is the .machine file: granularity:1 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 1:node91 I would appreciate your help. Best, Jianpeng ___ 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
[Wien] Errors in WIENNCM
Dear Wien2k users and developers, I am using wienncm to do some non-collinear magnetic calculations. I have compiled both wien2k 17.1 and wienncm successfully, and I am able to run wien2k in both serial and parallel mode. But the noncollinear calculations always crush at the lapw1 level for wienncm. To be specific, I tried to re-calculate the uo2_3k example in serial mode on a cluster with ifort compiler and mkl libraries (version 2013_sp1.2.144), but got the following error: *** glibc detected *** /home/jpliu/WIENNCM/lapw1c: free(): corrupted unsorted chunks: 0x02516ea0 I did the same calculation with wienncm on a different cluster on which a different version of ifort and mkl (composer_xe_2015.2.164) is installed. Again, the code is compiled without any error report, and wien2k runs perfectly, but wienncm crushes at the lapw1 step with the following error message: *** glibc detected *** /home/jpliu/WIENNCM/lapw1c: double free or corruption (out): 0x012afaf0 *** Such errors look similar to the "blocksize" bug as shown in the following link: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2015-March/022545.html But I am not sure. May it is due to the incompatibility between wien2k 17.1 and wienncm? Attached please see the full error reports (error1 and error2). I would appreciate your help. Jianpeng error1 Description: Binary data error2 Description: Binary data ___ 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
