Re: [Wien] Magnetocrystalline anisotropy

[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 read the complex part !!!

And third:the vorb* potential should be applied only once.

It can be done in   x lapw1 -orb -up/dn  OR in
x lapwso -orb -up
but not in both.

Application in lapwso also includes cross terms between spin-up and dn, 
while in lapw1 it excludes them.


When reporting differences between wien2k_16 and 17, you have to find 
out, what causes these differences.
a) compare case.vorbup/dn in both cases. Are they the same/similar ? In 
particular with respect to symmetry (+m and -m terms symmetric ???)

b) run lapwso of 17 with vorbs of 16 and vice versa.

If nothing helps, send me your struct file + some details (inputs) and 
I'll check it myself.


Peter


Am 16.01.2018 um 17:57 schrieb 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 the second case.


I have a second question regarding the reading of these orbital 
potential files. We noticed the orb program read only the real part, 
neglecting the imaginary one (Prof. Marks already noticed it in the 
source code). Due to our energy scale which is tiny, could we expect an 
impact of such approximation ? Considering your last comments, it seems 
not due to the execution of the orb program only in lapw1 and not during 
the perturbative procedure.


Thank you by advance.

All the best,

William Lafargue-dit-Hauret


Le 16/01/2018 à 17:05, Xavier Rocquefelte a écrit :

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 -dn  -c




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 the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for EECE.

You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones 
obtained in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 

Re: [Wien] Magnetocrystalline anisotropy

[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
runsp_lapw -eece -p -ec 0.1 -NI -so

Then for larger EMAX and kmesh, edit case.inso and  witht SO do :

x lapw1 -up -c
x lapw1 -dn -c

And for the different magnetization directions we do:

x lapwso -c -up -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

---
Concerning the two question William asked:

1) -eece does not have vorbdu as nobody (to my knowledge) has worked
out what it should be. For certain I don't know!

2) I am not sure about this. Is the imaginary component neglected for
lapw1 -c? For a d-state (as you have) maybe from time-reversal vorb
has to be centro-symmetric so there should be no imaginary term. This
does not seem right for p or f states. Unfortunately it is more than a
year since I worried about this, so I cannot remember.

On Tue, Jan 16, 2018 at 11:02 AM, Xavier Rocquefelte
 wrote:
> 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 directions we do:
>
> x lapwso -c -up
> x lapw2 -so -up  -c
> x lapw2 -so -dn  -c
>
>
> In other words, we do not put -orb in lapwso. It seems that this option was
> leading to problems depending on the magnetic system.
>
> Best Regards
> Xavier
>
>
> Le 16/01/2018 à 17:57, William Lafargue-dit-Hauret a écrit :
>
> 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 the second case.
>
> I have a second question regarding the reading of these orbital potential
> files. We noticed the orb program read only the real part, neglecting the
> imaginary one (Prof. Marks already noticed it in the source code). Due to
> our energy scale which is tiny, could we expect an impact of such
> approximation ? Considering your last comments, it seems not due to the
> execution of the orb program only in lapw1 and not during the perturbative
> procedure.
>
> Thank you by advance.
>
> All the best,
>
> William Lafargue-dit-Hauret
>

-- 
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what
nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu
Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
Co-Editor, Acta Cryst A
___
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] Magnetocrystalline anisotropy

[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 directions we do:

x lapwso -c -up
x lapw2 -so -up  -c
x lapw2 -so -dn  -c


In other words, we do not put -orb in lapwso. It seems that this option 
was leading to problems depending on the magnetic system.


Best Regards
Xavier

Le 16/01/2018 à 17:57, William Lafargue-dit-Hauret a écrit :


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 the second case.


I have a second question regarding the reading of these orbital 
potential files. We noticed the orb program read only the real part, 
neglecting the imaginary one (Prof. Marks already noticed it in the 
source code). Due to our energy scale which is tiny, could we expect 
an impact of such approximation ? Considering your last comments, it 
seems not due to the execution of the orb program only in lapw1 and 
not during the perturbative procedure.


Thank you by advance.

All the best,

William Lafargue-dit-Hauret


Le 16/01/2018 à 17:05, Xavier Rocquefelte a écrit :

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 -dn  -c




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 the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for 
EECE.


You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a 
correct kmesh we still obtain non-symmetric MAE, namely MAE 
along [0 1 0] and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones 
obtained in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of 
case.vorbup, case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are 
symmetric, while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is 

Re: [Wien] Magnetocrystalline anisotropy

[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 the second case.


I have a second question regarding the reading of these orbital 
potential files. We noticed the orb program read only the real part, 
neglecting the imaginary one (Prof. Marks already noticed it in the 
source code). Due to our energy scale which is tiny, could we expect an 
impact of such approximation ? Considering your last comments, it seems 
not due to the execution of the orb program only in lapw1 and not during 
the perturbative procedure.


Thank you by advance.

All the best,

William Lafargue-dit-Hauret


Le 16/01/2018 à 17:05, Xavier Rocquefelte a écrit :

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 -dn  -c




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 the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for EECE.

You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones 
obtained in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are 
symmetric, while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT 
present.


  * Say *"YES"* in all cases except when you do *spin-polarized
    (magnetic) calculations WITH spin-orbit coupling * (this breaks
    time-inversion symmetry and thus one MUST NOT add inversion
    symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit 
calculations by doing : x kgen -fbz, then you obtain a symmetric 
magnetic anisotrop. In conclusion the asymmetry I obtained was 
due to an improper definition of the kmesh (adding artificially 
time-inversion).


I want to thank all the 

Re: [Wien] Magnetocrystalline anisotropy

[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 -dn  -c




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 the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for EECE.

You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones 
obtained in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, 
while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT 
present.


  * Say *"YES"* in all cases except when you do *spin-polarized
(magnetic) calculations WITH spin-orbit coupling * (this breaks
time-inversion symmetry and thus one MUST NOT add inversion
symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit 
calculations by doing : x kgen -fbz, then you obtain a symmetric 
magnetic anisotrop. In conclusion the asymmetry I obtained was 
due to an improper definition of the kmesh (adding artificially 
time-inversion).


I want to thank all the participants who answered to my question. 
It was essential to identify such a mistake which has a huge 
impact on the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also 
observed experimentally). It is related to the monoclinic 
symmetry of the system which permits it. However, you gave me an 
idea that I will test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric 
curve, isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 

Re: [Wien] Magnetocrystalline anisotropy

[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 the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for EECE.

You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones 
obtained in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, 
while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT 
present.


  * Say *"YES"* in all cases except when you do *spin-polarized
(magnetic) calculations WITH spin-orbit coupling * (this breaks
time-inversion symmetry and thus one MUST NOT add inversion
symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit 
calculations by doing : x kgen -fbz, then you obtain a symmetric 
magnetic anisotrop. In conclusion the asymmetry I obtained was 
due to an improper definition of the kmesh (adding artificially 
time-inversion).


I want to thank all the participants who answered to my question. 
It was essential to identify such a mistake which has a huge 
impact on the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also 
observed experimentally). It is related to the monoclinic 
symmetry of the system which permits it. However, you gave me an 
idea that I will test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric 
curve, isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
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 

Re: [Wien] Magnetocrystalline anisotropy

[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. It must not be there for EECE.

You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present (from 
previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones obtained 
in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, 
while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT 
present.


  * Say *"YES"* in all cases except when you do *spin-polarized
    (magnetic) calculations WITH spin-orbit coupling * (this breaks
    time-inversion symmetry and thus one MUST NOT add inversion
    symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit calculations 
by doing : x kgen -fbz, then you obtain a symmetric magnetic 
anisotrop. In conclusion the asymmetry I obtained was due to an 
improper definition of the kmesh (adding artificially time-inversion).


I want to thank all the participants who answered to my question. 
It was essential to identify such a mistake which has a huge impact 
on the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also 
observed experimentally). It is related to the monoclinic symmetry 
of the system which permits it. However, you gave me an idea that 
I will test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric curve, 
isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
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 

Re: [Wien] Magnetocrystalline anisotropy

[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 -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

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 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present (from 
previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones obtained 
in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, 
while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT 
present.


  * Say *"YES"* in all cases except when you do *spin-polarized
(magnetic) calculations WITH spin-orbit coupling * (this breaks
time-inversion symmetry and thus one MUST NOT add inversion
symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit calculations 
by doing : x kgen -fbz, then you obtain a symmetric magnetic 
anisotrop. In conclusion the asymmetry I obtained was due to an 
improper definition of the kmesh (adding artificially time-inversion).


I want to thank all the participants who answered to my question. 
It was essential to identify such a mistake which has a huge impact 
on the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also 
observed experimentally). It is related to the monoclinic symmetry 
of the system which permits it. However, you gave me an idea that 
I will test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric curve, 
isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
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 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

Re: [Wien] Magnetocrystalline anisotropy

[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 always 
the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present (from 
previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] and 
[0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones obtained in 
GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, 
while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT present.

  * Say *"YES"* in all cases except when you do *spin-polarized
(magnetic) calculations WITH spin-orbit coupling * (this breaks
time-inversion symmetry and thus one MUST NOT add inversion
symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit calculations by 
doing : x kgen -fbz, then you obtain a symmetric magnetic anisotrop. 
In conclusion the asymmetry I obtained was due to an improper 
definition of the kmesh (adding artificially time-inversion).


I want to thank all the participants who answered to my question. It 
was essential to identify such a mistake which has a huge impact on 
the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also observed 
experimentally). It is related to the monoclinic symmetry of the 
system which permits it. However, you gave me an idea that I will 
test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric curve, 
isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
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 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



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

Re: [Wien] Magnetocrystalline anisotropy

[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 matters.

The first caveat is that there can be large change in the orbital
occupancies with -so/orb. This is a rotation of the density matrix or
orbital potential, and rotations are poorly handled in Taylor
expansions (which all mixers are).

The second caveat is that when one reduces symmetry there can be
additional soft modes which only poorly converge.

On Tue, Jan 16, 2018 at 8:09 AM, Xavier Rocquefelte
 wrote:
> 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 PhD student William Lafargue-dit-Hauret) were exactly
> working along this line ... our preliminary results are not consistent.
>
> c) we didn't try this option ... we will try
>
> Thank you for your quick reply Laurence
>
> Best Regards
>
> Xavier
>
>
>
> Le 16/01/2018 à 15:03, Laurence Marks a écrit :
>> 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 small so this should not matter.
>> b) Hack the runsp_lapw script so that -orb is applied to lapw1, not in lapwso
>> c) Run without the up/dn component (-noorbud)
>>
>> On Tue, Jan 16, 2018 at 7:50 AM, Xavier Rocquefelte
>>  wrote:
>>> Here is a document showing the results graphically.
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__filesender.renater.fr_-3Fs-3Ddownload-26token-3D8ac3a214-2Dedfa-2D4894-2Dfa1f-2D27aba5a5522f=DwIGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=mfZINSS9VKVdzwe4U7cSmx0-ziyAHYu8JU6ZTl7KjeM=4O827iUX43sWWhwFi99lMba-6xHX3nxPAXPuikEN73k=
>>>
>>> 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 not WIEN2k_17.
>>>
>>> We are now comparing the two versions of the code.
>>>
>>> Regards
>>>
>>> Xavier
>>>
>>>
>>> Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :
>>>
>>> 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 GGA+U+SO or EECE+SO with a correct kmesh we
>>> still obtain non-symmetric MAE, namely MAE along [0 1 0] and [0 -1 0] are
>>> different.
>>>
>>> In addition, the so obtained MAE looks similar to the ones obtained in
>>> GGA+SO with a bad kmesh (including temporal symmetry).
>>>
>>> At this moment, we are checking all the recent modifications in SRC_ORB and
>>> SRC_LAPW2 related to the manipulation of case.vorbup, case.vorbdn and
>>> case.vorbud files.
>>>
>>> Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, while not
>>> in WIEN2k_17.
>>>
>>> Next soon ... I hope.
>>>
>>> Xavier
>>>
>>>
>>> Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :
>>>
>>> Dear All
>>>
>>> The problem is solved and was related to one stupid human mistake.
>>>
>>> It was necessary to generate a kmesh without adding inversion
>>> (time-inversion symmetry).
>>> Indeed, as mentionned in the userguide when using kgen program:
>>>
>>> "add inversion" ? This is asked only when inversion is NOT present.
>>>
>>> Say "YES" in all cases except when you do spin-polarized (magnetic)
>>> calculations WITH spin-orbit coupling (this breaks time-inversion symmetry
>>> and thus one MUST NOT add inversion symmetry (eigenvalues at +k and -k may
>>> be different).
>>>
>>> If you properly generate the kmesh for the spin-orbit calculations by doing
>>> : x kgen -fbz, then you obtain a symmetric magnetic anisotrop. In conclusion
>>> the asymmetry I obtained was due to an improper definition of the kmesh
>>> (adding artificially time-inversion).
>>>
>>> I want to thank all the participants who answered to my question. It was
>>> essential to identify such a mistake which has a huge impact on the results.
>>>
>>> Best wishes
>>>
>>> Xavier
>>>
>>>
>>>
>>> Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :
>>>
>>> Dear Lyudmila
>>>
>>> The fact we have a small angle with axes is expected (also observed
>>> experimentally). It is related to the monoclinic symmetry of the 

Re: [Wien] Magnetocrystalline anisotropy

[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 PhD student William Lafargue-dit-Hauret) were exactly 
working along this line ... our preliminary results are not consistent.


c) we didn't try this option ... we will try

Thank you for your quick reply Laurence

Best Regards

Xavier



Le 16/01/2018 à 15:03, Laurence Marks a écrit :

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 small so this should not matter.
b) Hack the runsp_lapw script so that -orb is applied to lapw1, not in lapwso
c) Run without the up/dn component (-noorbud)

On Tue, Jan 16, 2018 at 7:50 AM, Xavier Rocquefelte
 wrote:

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 not WIEN2k_17.

We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :

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 GGA+U+SO or EECE+SO with a correct kmesh we
still obtain non-symmetric MAE, namely MAE along [0 1 0] and [0 -1 0] are
different.

In addition, the so obtained MAE looks similar to the ones obtained in
GGA+SO with a bad kmesh (including temporal symmetry).

At this moment, we are checking all the recent modifications in SRC_ORB and
SRC_LAPW2 related to the manipulation of case.vorbup, case.vorbdn and
case.vorbud files.

Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, while not
in WIEN2k_17.

Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :

Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion
(time-inversion symmetry).
Indeed, as mentionned in the userguide when using kgen program:

"add inversion" ? This is asked only when inversion is NOT present.

Say "YES" in all cases except when you do spin-polarized (magnetic)
calculations WITH spin-orbit coupling (this breaks time-inversion symmetry
and thus one MUST NOT add inversion symmetry (eigenvalues at +k and -k may
be different).

If you properly generate the kmesh for the spin-orbit calculations by doing
: x kgen -fbz, then you obtain a symmetric magnetic anisotrop. In conclusion
the asymmetry I obtained was due to an improper definition of the kmesh
(adding artificially time-inversion).

I want to thank all the participants who answered to my question. It was
essential to identify such a mistake which has a huge impact on the results.

Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also observed
experimentally). It is related to the monoclinic symmetry of the system
which permits it. However, you gave me an idea that I will test now and
comment soon ;)

Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:

I see in the FM calculation also a slightly non-symmetric curve, isn't it?


I meant the small angle with axes.

Best wishes
Lyudmila Dobysheva

___
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 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

Re: [Wien] Magnetocrystalline anisotropy

[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 small so this should not matter.
b) Hack the runsp_lapw script so that -orb is applied to lapw1, not in lapwso
c) Run without the up/dn component (-noorbud)

On Tue, Jan 16, 2018 at 7:50 AM, Xavier Rocquefelte
 wrote:
> 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 not WIEN2k_17.
>
> We are now comparing the two versions of the code.
>
> Regards
>
> Xavier
>
>
> Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :
>
> 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 GGA+U+SO or EECE+SO with a correct kmesh we
> still obtain non-symmetric MAE, namely MAE along [0 1 0] and [0 -1 0] are
> different.
>
> In addition, the so obtained MAE looks similar to the ones obtained in
> GGA+SO with a bad kmesh (including temporal symmetry).
>
> At this moment, we are checking all the recent modifications in SRC_ORB and
> SRC_LAPW2 related to the manipulation of case.vorbup, case.vorbdn and
> case.vorbud files.
>
> Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, while not
> in WIEN2k_17.
>
> Next soon ... I hope.
>
> Xavier
>
>
> Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :
>
> Dear All
>
> The problem is solved and was related to one stupid human mistake.
>
> It was necessary to generate a kmesh without adding inversion
> (time-inversion symmetry).
> Indeed, as mentionned in the userguide when using kgen program:
>
> "add inversion" ? This is asked only when inversion is NOT present.
>
> Say "YES" in all cases except when you do spin-polarized (magnetic)
> calculations WITH spin-orbit coupling (this breaks time-inversion symmetry
> and thus one MUST NOT add inversion symmetry (eigenvalues at +k and -k may
> be different).
>
> If you properly generate the kmesh for the spin-orbit calculations by doing
> : x kgen -fbz, then you obtain a symmetric magnetic anisotrop. In conclusion
> the asymmetry I obtained was due to an improper definition of the kmesh
> (adding artificially time-inversion).
>
> I want to thank all the participants who answered to my question. It was
> essential to identify such a mistake which has a huge impact on the results.
>
> Best wishes
>
> Xavier
>
>
>
> Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :
>
> Dear Lyudmila
>
> The fact we have a small angle with axes is expected (also observed
> experimentally). It is related to the monoclinic symmetry of the system
> which permits it. However, you gave me an idea that I will test now and
> comment soon ;)
>
> Cheers
>
> Xavier
>
> Le 10/01/2018 à 10:40, Lyudmila a écrit :
>
> 10.01.2018 13:36, Lyudmila wrote:
>
> I see in the FM calculation also a slightly non-symmetric curve, isn't it?
>
>
> I meant the small angle with axes.
>
> Best wishes
> Lyudmila Dobysheva
>
> ___
> 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 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
>
>



-- 
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what
nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu
Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
Co-Editor, Acta Cryst A
___
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] Magnetocrystalline anisotropy

[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 not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


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 GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] and 
[0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones obtained in 
GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, 
while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT present.

  * Say *"YES"* in all cases except when you do *spin-polarized
(magnetic) calculations WITH spin-orbit coupling * (this breaks
time-inversion symmetry and thus one MUST NOT add inversion
symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit calculations by 
doing : x kgen -fbz, then you obtain a symmetric magnetic anisotrop. 
In conclusion the asymmetry I obtained was due to an improper 
definition of the kmesh (adding artificially time-inversion).


I want to thank all the participants who answered to my question. It 
was essential to identify such a mistake which has a huge impact on 
the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also observed 
experimentally). It is related to the monoclinic symmetry of the 
system which permits it. However, you gave me an idea that I will 
test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric curve, 
isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
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 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

Re: [Wien] Magnetocrystalline anisotropy

[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 GGA+U+SO or EECE+SO with a correct kmesh 
we still obtain non-symmetric MAE, namely MAE along [0 1 0] and [0 -1 0] 
are different.


In addition, the so obtained MAE looks similar to the ones obtained in 
GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in SRC_ORB 
and SRC_LAPW2 related to the manipulation of case.vorbup, case.vorbdn 
and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are symmetric, while 
not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT present.

  * Say *"YES"* in all cases except when you do *spin-polarized
(magnetic) calculations WITH spin-orbit coupling * (this breaks
time-inversion symmetry and thus one MUST NOT add inversion
symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit calculations by 
doing : x kgen -fbz, then you obtain a symmetric magnetic anisotrop. 
In conclusion the asymmetry I obtained was due to an improper 
definition of the kmesh (adding artificially time-inversion).


I want to thank all the participants who answered to my question. It 
was essential to identify such a mistake which has a huge impact on 
the results.


Best wishes

Xavier



Le 10/01/2018 à 10:47, Xavier Rocquefelte a écrit :

Dear Lyudmila

The fact we have a small angle with axes is expected (also observed 
experimentally). It is related to the monoclinic symmetry of the 
system which permits it. However, you gave me an idea that I will 
test now and comment soon ;)


Cheers

Xavier

Le 10/01/2018 à 10:40, Lyudmila a écrit :

10.01.2018 13:36, Lyudmila wrote:
I see in the FM calculation also a slightly non-symmetric curve, 
isn't it?


I meant the small angle with axes.


Best wishes
Lyudmila Dobysheva

___
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 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