Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
Dear All Finally the problem is not completely solved. More precisely, when we are doing GGA+SO calculations and using a correct kmesh (no temporal symmetry), we obtain a symmetric magnetocrystalline anisotropy, namely same MAE along [0 1 0] and [0 -1 0]. In contrast, when we are doing

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread William Lafargue-dit-Hauret
Dear Profs. Blaha and Marks, Thank you for your advices. I have a question regarding your comment on the EECE case. The resulting effective potential of LDA+U and EECE corrections is decomposed in vorb files, but I don't understand why the spin-coupling file case.vorbud shouldn't appear in

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
Dear Peter and Laurence Thank you for your replies. Using the following strategy it seems to work nicely (preliminary results): runsp_lapw -eece -p -ec 0.1 -NI Then for larger EMAX and kmesh without SO we do : x lapw1 -up -c -orb x lapw1 -dn -c -orb And for the different magnetization

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Laurence Marks
Dear Xavier, The method you just used avoids time-reversal symmetry for -orb. My intuition is that this is right, but I don't think I ever convinced Peter of this. An alternative (that might be wrong) and avoids double counting is: Setup case.inso with NO spin-orbit on any atom, then do

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
Here is a document showing the results graphically. https://filesender.renater.fr/?s=download=8ac3a214-edfa-4894-fa1f-27aba5a5522f It really looks like the problem we had before (using bad kmesh). We test it on two different compounds and in both cases WIEN2k_16 gives a correct picture and

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
Dear Laurence Here is the point. Our results show that in version 17 a problem occurs related to the time-reversal, which appears only if we do GGA+U or EECE. a) The calculations we showed are already done in P1. Indeed, I wanted to avoid any problems related to symmetry. b) we (me and my

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Peter Blaha
Hallo Xavier, Looks rather strange. Eventually I would have expected problems both, in 16.1 and 17.1 (but not 14.2) due to the off-diagonal density matrices. But this should concern ONLY LDA+U, not -eece. Just to be sure: I expect you do SO non-selfconsistent, so vorbup/dn(du) files are

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
Dear Peter You are totally correct. We are doing SO non-selfconsistent by using a standard procedure for EECE calculations: runsp_lapw -eece -p -ec 0.1 -NI and then we estimate the MAE using this non-SCF procedure : Increase EMAX in case.in1c - increase kmesh if needed x lapw1 -up

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
OK we will check it. In EECE we have no case.vorbud file (empty file). Le 16/01/2018 à 16:58, Peter Blaha a écrit : Hups: If this is true, you are counting the orbital potential twice ! -orb should only be present in the lapwso step. (And in fact, the lapw1 steps need to be done just once for

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Peter Blaha
Hups: If this is true, you are counting the orbital potential twice ! -orb should only be present in the lapwso step. (And in fact, the lapw1 steps need to be done just once for the increased k-mesh; but not when changing the M-direction in case.inso) Please check the presence of case.vorbud.

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Xavier Rocquefelte
I was not clear Peter. I clarify the way we proceed. We do runsp_lapw -eece -p -ec 0.1 -NI Then for larger EMAX and kmesh without SO we do : x lapw1 -up -c -orb x lapw1 -dn -c -orb And for the different magnetization directions we do: x lapwso -c -up -orb x lapw2 -so -up -c x lapw2 -so

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Peter Blaha
Just a few comments: In many posts to this topic I saw the -c switch. This is not necessary and prone to errors. Don't use -c . It will be done automatically. I think, the orb program reads case.dmat* files, and produces case.vorb* files. It is not reading vorb files. And it does

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Laurence Marks
Dear Xavier, One other suggestion, with a caveat. In general if the physical model is weak/wrong or there are coding errors, the convergence is poor. This has to do with what I call "noise" in the calculation (for want of a better term). Since the mixing is implicitly a Simplex derivative noise

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread Laurence Marks
I may annoy Peter with the comment below, so it goes Personally I have some reservations about the consistency between the orbital potential and time-reversal operations in -so. Three possible tests: a) Reduce the symmetry to P1 and run. While this is slower, I believe your test case is