Re: [Wien] wien2wannier with SOC in WIEN2k 16.1

2016-12-15 Thread Peter Blaha
I've corrected the version on the web. Just download SRC.tar.gz. It also contains a small fix for all run*_lapw scripts (VERSION in scf files corrected). On 12/15/2016 08:44 PM, Elias Assmann wrote: Dear Kefeng Wang, On 12/15/2016 06:01 PM, Kefeng Wang wrote: 2. Then I run “init_w2w

Re: [Wien] wien2wannier with SOC in WIEN2k 16.1

2016-12-15 Thread Fecher, Gerhard
With SO each wave function will still have a "up" and a ""down" part, but they are connected and cannot be separated, (indeed not s(1/2,+1/2) or s(1/2,-1/2), at least in the 2 component version they are purely up or down, as well as all others with j=l+s, mj=+-j). how does Wannier deal with the

Re: [Wien] wien2wannier with SOC in WIEN2k 16.1

2016-12-15 Thread Elias Assmann
On 12/15/2016 10:13 PM, Kefeng Wang wrote: > Thanks a lot for your help and explanation. With the new script > write_inwf_lapw, everything works fine now. Great. > ->For this one, the exact error message is “recommended file > ‘GaAs.spaghetti_ene’ not found (will continue)”. But it does not

Re: [Wien] wien2wannier with SOC in WIEN2k 16.1

2016-12-15 Thread Kefeng Wang
Dear Elias, Thanks a lot for your help and explanation. With the new script write_inwf_lapw, everything works fine now. > 1. Then I run *prepare_w2wdir WANN, but this command cannot > recognize Case.spaghettiup_ene and Case.Spaghettidn_ene file, > instead it shows "cannot find

Re: [Wien] wien2wannier with SOC in WIEN2k 16.1

2016-12-15 Thread Elias Assmann
Dear Kefeng Wang, On 12/15/2016 06:01 PM, Kefeng Wang wrote: > 2. Then I run “init_w2w –up”, after k mesh (10 10 10) and find > band, “write_inwf” shows “error: unrecognized arguments: -up” and > init_w2w exit. I also found the help file did not include [-up/dn] > option for write_inwf

Re: [Wien] WIEN2k_16

2016-12-15 Thread delamora
It is me again, in the initialization instead of having the steps in BOLD - next is setrmt next is nn It has this structure; -- [1m next is setrmt (B [1m next is nn (B Now I was able to compile and run WIEN2k-16.1 But I found in

Re: [Wien] WIEN2k_16

2016-12-15 Thread delamora
Now I was able to compile and run WIEN2k-16.1 But I found in the initialize calculation that it starts with; -- [1m next is setrmt (B [1m next is nn (B specify nn-bondlength factor --- and it finishes with; -> new Na-2.in0 generated [1m

Re: [Wien] WIEN2k_16

2016-12-15 Thread delamora
Thank you very much Pablo De: Wien en nombre de Martin Kroeker Enviado: jueves, 15 de diciembre de 2016 01:58:58 a. m. Para: wien@zeus.theochem.tuwien.ac.at Asunto: [Wien] WIEN2k_16

[Wien] wien2wannier with SOC in WIEN2k 16.1

2016-12-15 Thread Kefeng Wang
Dear developers and user community, I am trying to run wien2wannier in the new WIEN2k 16.1 on a simple case GaAs with spin polarization and spin orbital coupling. I met some problems. My platform and other information: WIEN2k 16.1, x86_64, linux, intel compiler ifort and mkl (2016.1)

Re: [Wien] incorrect band splitting when RLO added for a system with spatial inversion

2016-12-15 Thread Peter Blaha
Is this all converged with respect to EMAX in case.in1 ??? So from your figure one would find that these bands at EF are affected by >0.1 eV when you add a p1/2 basis function at -8 Ry This sounds VERY strange to me and I don't know if one can explain this by an "orthogonality effect"

Re: [Wien] incorrect band splitting when RLO added for a system with spatial inversion

2016-12-15 Thread Martin Gmitra
Dear Peter, Thank you for your answer. The main reason to use the RLO is the effect close to the Fermi level, where the top valence and bottom conduction bands are strongly pushed towards each other due to spin-orbit coupling. In the attached figure you can find plot for the different cases.