Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Peter Blaha]

No, I did NOT do any constrains.

runsp -orb
save_lapw ...
runsp -eece

absolutely no convergence problems !!!

PS: My current ifort version (2016.3.210) fails to compile lapwdm 
properly. It over-optimizes even with -O1. Had to use -O0, otherwise I 
got runtime errors.


On 01/23/2017 08:08 AM, Xavier Rocquefelte wrote:

Thank you Peter for your reply. I had no doubt that it was possible to
converge the calculation using such strategy. My point was that such
calculation was easy to converge starting from the scratch, directly
using PBE0 and without constraining the total magnetic moment of the
unit cell. At this moment I do not know if the problem is related to the
mixer or to the PBE0 on-site. Indeed, I can imagine that not only mixer
has changed but also PBE0 onsite compared to the WIEN2k version I was
using in 2008. I plan to do the test Fabien has proposed.

Best wishes

Xavier


Le 23/01/2017 à 07:00, Peter Blaha a écrit :

Sorry, but I cannot reproduce this.

Starting from a converged GGA+U calculation, -eece converges smoothly,
keeps the :mmt at 8 uB and a reasonable gap of 1.6 eV and :MV goes to
10-4.

(quick test with few k-points and rkmax only 6.5)

Am 20.01.2017 um 22:16 schrieb Laurence Marks:

I can provide some partial responses, although there are also some
things that I don't understand. Some of this (maybe most) is not the
mixer but in other parts of Wien2k.

First, the old (2008) version is there if you use MSEC1, but I have not
tested it and it may fail. Better is to use MSEC3 which is almost the
old version. For some classes of problems this is more stable than MSR1,
and works better. If you are talking about the pre-multisecant version
(BROYD) that vanished some time ago.

Second, there is a nasty "feature" particularly for +U (eece) cases,
which is partially discussed in the mixer Readme. There is no guarantee
that a solution exists -- the KS theorem is for densities but U is an
orbital term. It is very possible to have cases where there is no
fixed-point solution. The older MSEC1 (maybe BROYD) could find a fake
solution where the density was consistent but the orbital potential was
not. The latest version is much better in avoiding them and going for
"real" solutions rather than being trapped. For orbital potentials it is
very important to look at :MV to check that one really has a
self-consistent orbital potential.

Third, there are cases where PBE (and all the GGA's in Wien2k that I
have tested) give unphysical results when applied to isolated d or f
electrons as done for -eece. I guess that the GGA functionals were not
designed for the densities of just high L orbitals. This leads to very
bad behavior of the mixing. I know of no way to solve this in the mixer,
it is a structural problem. It goes away if LDA is used as the form for
VXC in -eece.

Fourth, larger problem with low symmetry (P1 in particular) can
certainly behave badly. Part of this might be "somewhere" in Wien2k
coding, part of it is generic to a low symmetry problem. In many cases
these have small eigenvalues in the mixing Jacobian which are removed
when symmetry is imposed. All one can do is use MSEC3 or some of the
additional flags (see the mixer README) such as "SLOW".

Fifth...probably exists, but I can't think of it immediately.

On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte
> wrote:

Dear Colleagues

I did recently a calculation which has been published long time ago
using a old WIEN2k version (in 2008).

It corresponds to a spin-polarized calculation for the compound
CuO. The
symmetry is removed and the idea is to estimate the total
energies for
different magnetic orders to extract magnetic couplings from a
mapping
analysis. Such calculations were converging fastly without any
trouble
in 2008.

Here I have started from the scratch with a case.cif file to
generate
the case.struct file and initializing the calculation in a standard
manner.

Then I wanted to have the energy related to a ferromagnetic
situation
(not the more stable). I have 8 copper sites in the unit cell I am
using.

When this calculation is done using PBE+U everything goes fine.
However
when PBE0 hybrid on-site functional is used we observed
oscillations and
the magnetic moment disappear, which is definitely not correct. It
should be mentionned that the convergency is really bad. If we do a
similar calculation on the cristallographic unit cell (2 copper
sites
only) the calculations converge both in PBE+U and PBE0.

The convergency problems only arises for low-symmetry and high
number of
magnetic elements. I didn't have such problems before and I
wonder if we
could still use old mixer scheme in such situations. Looking at the
userguide, it seems that the mixer does not allow to do as before
and
PRATT mixer is too slow.

Did you encounter similar 

Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Xavier Rocquefelte]

Thank you Peter for your reply. I had no doubt that it was possible to 
converge the calculation using such strategy. My point was that such 
calculation was easy to converge starting from the scratch, directly 
using PBE0 and without constraining the total magnetic moment of the 
unit cell. At this moment I do not know if the problem is related to the 
mixer or to the PBE0 on-site. Indeed, I can imagine that not only mixer 
has changed but also PBE0 onsite compared to the WIEN2k version I was 
using in 2008. I plan to do the test Fabien has proposed.


Best wishes

Xavier


Le 23/01/2017 à 07:00, Peter Blaha a écrit :

Sorry, but I cannot reproduce this.

Starting from a converged GGA+U calculation, -eece converges smoothly, 
keeps the :mmt at 8 uB and a reasonable gap of 1.6 eV and :MV goes to 
10-4.


(quick test with few k-points and rkmax only 6.5)

Am 20.01.2017 um 22:16 schrieb Laurence Marks:

I can provide some partial responses, although there are also some
things that I don't understand. Some of this (maybe most) is not the
mixer but in other parts of Wien2k.

First, the old (2008) version is there if you use MSEC1, but I have not
tested it and it may fail. Better is to use MSEC3 which is almost the
old version. For some classes of problems this is more stable than MSR1,
and works better. If you are talking about the pre-multisecant version
(BROYD) that vanished some time ago.

Second, there is a nasty "feature" particularly for +U (eece) cases,
which is partially discussed in the mixer Readme. There is no guarantee
that a solution exists -- the KS theorem is for densities but U is an
orbital term. It is very possible to have cases where there is no
fixed-point solution. The older MSEC1 (maybe BROYD) could find a fake
solution where the density was consistent but the orbital potential was
not. The latest version is much better in avoiding them and going for
"real" solutions rather than being trapped. For orbital potentials it is
very important to look at :MV to check that one really has a
self-consistent orbital potential.

Third, there are cases where PBE (and all the GGA's in Wien2k that I
have tested) give unphysical results when applied to isolated d or f
electrons as done for -eece. I guess that the GGA functionals were not
designed for the densities of just high L orbitals. This leads to very
bad behavior of the mixing. I know of no way to solve this in the mixer,
it is a structural problem. It goes away if LDA is used as the form for
VXC in -eece.

Fourth, larger problem with low symmetry (P1 in particular) can
certainly behave badly. Part of this might be "somewhere" in Wien2k
coding, part of it is generic to a low symmetry problem. In many cases
these have small eigenvalues in the mixing Jacobian which are removed
when symmetry is imposed. All one can do is use MSEC3 or some of the
additional flags (see the mixer README) such as "SLOW".

Fifth...probably exists, but I can't think of it immediately.

On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte
> wrote:

Dear Colleagues

I did recently a calculation which has been published long time ago
using a old WIEN2k version (in 2008).

It corresponds to a spin-polarized calculation for the compound 
CuO. The
symmetry is removed and the idea is to estimate the total 
energies for
different magnetic orders to extract magnetic couplings from a 
mapping
analysis. Such calculations were converging fastly without any 
trouble

in 2008.

Here I have started from the scratch with a case.cif file to 
generate

the case.struct file and initializing the calculation in a standard
manner.

Then I wanted to have the energy related to a ferromagnetic 
situation

(not the more stable). I have 8 copper sites in the unit cell I am
using.

When this calculation is done using PBE+U everything goes fine. 
However
when PBE0 hybrid on-site functional is used we observed 
oscillations and

the magnetic moment disappear, which is definitely not correct. It
should be mentionned that the convergency is really bad. If we do a
similar calculation on the cristallographic unit cell (2 copper 
sites

only) the calculations converge both in PBE+U and PBE0.

The convergency problems only arises for low-symmetry and high 
number of
magnetic elements. I didn't have such problems before and I 
wonder if we

could still use old mixer scheme in such situations. Looking at the
userguide, it seems that the mixer does not allow to do as before 
and

PRATT mixer is too slow.

Did you encounter similar difficulties (which were not in older 
WIEN2k

versions)?

Best Regards

Xavier

Here is the case.struct:

blebleble
P   LATTICE,NONEQUIV.ATOMS: 16 1_P1
MODE OF CALC=RELA unit=bohr
  14.167163  6.46 11.993298 90.00 95.267000 90.00
ATOM  -1: X=0.8750 

Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Peter Blaha]

Sorry, but I cannot reproduce this.

Starting from a converged GGA+U calculation, -eece converges smoothly, 
keeps the :mmt at 8 uB and a reasonable gap of 1.6 eV and :MV goes to 10-4.


(quick test with few k-points and rkmax only 6.5)

Am 20.01.2017 um 22:16 schrieb Laurence Marks:

I can provide some partial responses, although there are also some
things that I don't understand. Some of this (maybe most) is not the
mixer but in other parts of Wien2k.

First, the old (2008) version is there if you use MSEC1, but I have not
tested it and it may fail. Better is to use MSEC3 which is almost the
old version. For some classes of problems this is more stable than MSR1,
and works better. If you are talking about the pre-multisecant version
(BROYD) that vanished some time ago.

Second, there is a nasty "feature" particularly for +U (eece) cases,
which is partially discussed in the mixer Readme. There is no guarantee
that a solution exists -- the KS theorem is for densities but U is an
orbital term. It is very possible to have cases where there is no
fixed-point solution. The older MSEC1 (maybe BROYD) could find a fake
solution where the density was consistent but the orbital potential was
not. The latest version is much better in avoiding them and going for
"real" solutions rather than being trapped. For orbital potentials it is
very important to look at :MV to check that one really has a
self-consistent orbital potential.

Third, there are cases where PBE (and all the GGA's in Wien2k that I
have tested) give unphysical results when applied to isolated d or f
electrons as done for -eece. I guess that the GGA functionals were not
designed for the densities of just high L orbitals. This leads to very
bad behavior of the mixing. I know of no way to solve this in the mixer,
it is a structural problem. It goes away if LDA is used as the form for
VXC in -eece.

Fourth, larger problem with low symmetry (P1 in particular) can
certainly behave badly. Part of this might be "somewhere" in Wien2k
coding, part of it is generic to a low symmetry problem. In many cases
these have small eigenvalues in the mixing Jacobian which are removed
when symmetry is imposed. All one can do is use MSEC3 or some of the
additional flags (see the mixer README) such as "SLOW".

Fifth...probably exists, but I can't think of it immediately.

On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte
> wrote:

Dear Colleagues

I did recently a calculation which has been published long time ago
using a old WIEN2k version (in 2008).

It corresponds to a spin-polarized calculation for the compound CuO. The
symmetry is removed and the idea is to estimate the total energies for
different magnetic orders to extract magnetic couplings from a mapping
analysis. Such calculations were converging fastly without any trouble
in 2008.

Here I have started from the scratch with a case.cif file to generate
the case.struct file and initializing the calculation in a standard
manner.

Then I wanted to have the energy related to a ferromagnetic situation
(not the more stable). I have 8 copper sites in the unit cell I am
using.

When this calculation is done using PBE+U everything goes fine. However
when PBE0 hybrid on-site functional is used we observed oscillations and
the magnetic moment disappear, which is definitely not correct. It
should be mentionned that the convergency is really bad. If we do a
similar calculation on the cristallographic unit cell (2 copper sites
only) the calculations converge both in PBE+U and PBE0.

The convergency problems only arises for low-symmetry and high number of
magnetic elements. I didn't have such problems before and I wonder if we
could still use old mixer scheme in such situations. Looking at the
userguide, it seems that the mixer does not allow to do as before and
PRATT mixer is too slow.

Did you encounter similar difficulties (which were not in older WIEN2k
versions)?

Best Regards

Xavier

Here is the case.struct:

blebleble
P   LATTICE,NONEQUIV.ATOMS: 16 1_P1
MODE OF CALC=RELA unit=bohr
  14.167163  6.46 11.993298 90.00 95.267000 90.00
ATOM  -1: X=0.8750 Y=0.7500 Z=0.8750
   MULT= 1  ISPLIT= 8
Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
LOCAL ROT MATRIX:1.000 0.000 0.000
  0.000 1.000 0.000
  0.000 0.000 1.000
ATOM  -2: X=0.1250 Y=0.2500 Z=0.6250
   MULT= 1  ISPLIT= 8
Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
LOCAL ROT MATRIX:1.000 0.000 0.000
  0.000 1.000 0.000
  0.000 0.000 1.000
ATOM  -3: X=0.1250 

Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Laurence Marks]

:MV is in case.scfm, e.g. grep :MV *.scf. A value of 1D-2 is well
converged, 1D0 is maybe OK, 1D1 or more is problematic and can indicate a
problem if :DIS etc is small.

N.B., you can also look at the quadrature fit of x lapw0 -eece in
case.output0

---
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
http://www.numis.northwestern.edu
Corrosion in 4D http://MURI4D.numis.northwestern.edu
Partner of the CFW 100% gender equity project, www.cfw.org/100-percent
Co-Editor, Acta Cryst A


On Jan 21, 2017 01:27, "Xavier Rocquefelte" <
xavier.rocquefe...@univ-rennes1.fr> wrote:

> Dear Laurence
>
> Thank you so much for your detailled replies.
>
> I agree that something curious happens here. In particular, my surprise is
> why the convergency is fast and leads to a ferromagnetic solution in GGA+U
> and not in PBE0 on-site hybrid. These two schemes must be quite similar in
> the way they correct the GGA eigenvalues. I will continue to test the
> different options of mixer. Just one question, I didn't know the :MV
> keyword. Where should I find it?
>
> Best Regards
>
> Xavier
> Le 20/01/2017 à 22:16, Laurence Marks a écrit :
>
> I can provide some partial responses, although there are also some things
> that I don't understand. Some of this (maybe most) is not the mixer but in
> other parts of Wien2k.
>
> First, the old (2008) version is there if you use MSEC1, but I have not
> tested it and it may fail. Better is to use MSEC3 which is almost the old
> version. For some classes of problems this is more stable than MSR1, and
> works better. If you are talking about the pre-multisecant version (BROYD)
> that vanished some time ago.
>
> Second, there is a nasty "feature" particularly for +U (eece) cases, which
> is partially discussed in the mixer Readme. There is no guarantee that a
> solution exists -- the KS theorem is for densities but U is an orbital
> term. It is very possible to have cases where there is no fixed-point
> solution. The older MSEC1 (maybe BROYD) could find a fake solution where
> the density was consistent but the orbital potential was not. The latest
> version is much better in avoiding them and going for "real" solutions
> rather than being trapped. For orbital potentials it is very important to
> look at :MV to check that one really has a self-consistent orbital
> potential.
>
> Third, there are cases where PBE (and all the GGA's in Wien2k that I have
> tested) give unphysical results when applied to isolated d or f electrons
> as done for -eece. I guess that the GGA functionals were not designed for
> the densities of just high L orbitals. This leads to very bad behavior of
> the mixing. I know of no way to solve this in the mixer, it is a structural
> problem. It goes away if LDA is used as the form for VXC in -eece.
>
> Fourth, larger problem with low symmetry (P1 in particular) can certainly
> behave badly. Part of this might be "somewhere" in Wien2k coding, part of
> it is generic to a low symmetry problem. In many cases these have small
> eigenvalues in the mixing Jacobian which are removed when symmetry is
> imposed. All one can do is use MSEC3 or some of the additional flags (see
> the mixer README) such as "SLOW".
>
> Fifth...probably exists, but I can't think of it immediately.
>
> On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte <
> xavier.rocquefe...@univ-rennes1.fr> wrote:
>
>> Dear Colleagues
>>
>> I did recently a calculation which has been published long time ago
>> using a old WIEN2k version (in 2008).
>>
>> It corresponds to a spin-polarized calculation for the compound CuO. The
>> symmetry is removed and the idea is to estimate the total energies for
>> different magnetic orders to extract magnetic couplings from a mapping
>> analysis. Such calculations were converging fastly without any trouble
>> in 2008.
>>
>> Here I have started from the scratch with a case.cif file to generate
>> the case.struct file and initializing the calculation in a standard
>> manner.
>>
>> Then I wanted to have the energy related to a ferromagnetic situation
>> (not the more stable). I have 8 copper sites in the unit cell I am using.
>>
>> When this calculation is done using PBE+U everything goes fine. However
>> when PBE0 hybrid on-site functional is used we observed oscillations and
>> the magnetic moment disappear, which is definitely not correct. It
>> should be mentionned that the convergency is really bad. If we do a
>> similar calculation on the cristallographic unit cell (2 copper sites
>> only) the calculations converge both in PBE+U and PBE0.
>>
>> The convergency problems only arises for low-symmetry and high number of
>> magnetic elements. I didn't have such problems before and I wonder if we
>> could still use old mixer scheme in such situations. Looking at the
>> userguide, it seems that the mixer does not allow to do as before and
>> PRATT mixer is too slow.
>>
>> Did you encounter similar 

Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Xavier Rocquefelte]

Dear Laurence

Thank you so much for your detailled replies.

I agree that something curious happens here. In particular, my surprise 
is why the convergency is fast and leads to a ferromagnetic solution in 
GGA+U and not in PBE0 on-site hybrid. These two schemes must be quite 
similar in the way they correct the GGA eigenvalues. I will continue to 
test the different options of mixer. Just one question, I didn't know 
the :MV keyword. Where should I find it?


Best Regards

Xavier

Le 20/01/2017 à 22:16, Laurence Marks a écrit :
I can provide some partial responses, although there are also some 
things that I don't understand. Some of this (maybe most) is not the 
mixer but in other parts of Wien2k.


First, the old (2008) version is there if you use MSEC1, but I have 
not tested it and it may fail. Better is to use MSEC3 which is almost 
the old version. For some classes of problems this is more stable than 
MSR1, and works better. If you are talking about the pre-multisecant 
version (BROYD) that vanished some time ago.


Second, there is a nasty "feature" particularly for +U (eece) cases, 
which is partially discussed in the mixer Readme. There is no 
guarantee that a solution exists -- the KS theorem is for densities 
but U is an orbital term. It is very possible to have cases where 
there is no fixed-point solution. The older MSEC1 (maybe BROYD) could 
find a fake solution where the density was consistent but the orbital 
potential was not. The latest version is much better in avoiding them 
and going for "real" solutions rather than being trapped. For orbital 
potentials it is very important to look at :MV to check that one 
really has a self-consistent orbital potential.


Third, there are cases where PBE (and all the GGA's in Wien2k that I 
have tested) give unphysical results when applied to isolated d or f 
electrons as done for -eece. I guess that the GGA functionals were not 
designed for the densities of just high L orbitals. This leads to very 
bad behavior of the mixing. I know of no way to solve this in the 
mixer, it is a structural problem. It goes away if LDA is used as the 
form for VXC in -eece.


Fourth, larger problem with low symmetry (P1 in particular) can 
certainly behave badly. Part of this might be "somewhere" in Wien2k 
coding, part of it is generic to a low symmetry problem. In many cases 
these have small eigenvalues in the mixing Jacobian which are removed 
when symmetry is imposed. All one can do is use MSEC3 or some of the 
additional flags (see the mixer README) such as "SLOW".


Fifth...probably exists, but I can't think of it immediately.

On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte 
> wrote:


Dear Colleagues

I did recently a calculation which has been published long time ago
using a old WIEN2k version (in 2008).

It corresponds to a spin-polarized calculation for the compound
CuO. The
symmetry is removed and the idea is to estimate the total energies for
different magnetic orders to extract magnetic couplings from a mapping
analysis. Such calculations were converging fastly without any trouble
in 2008.

Here I have started from the scratch with a case.cif file to generate
the case.struct file and initializing the calculation in a
standard manner.

Then I wanted to have the energy related to a ferromagnetic situation
(not the more stable). I have 8 copper sites in the unit cell I am
using.

When this calculation is done using PBE+U everything goes fine.
However
when PBE0 hybrid on-site functional is used we observed
oscillations and
the magnetic moment disappear, which is definitely not correct. It
should be mentionned that the convergency is really bad. If we do a
similar calculation on the cristallographic unit cell (2 copper sites
only) the calculations converge both in PBE+U and PBE0.

The convergency problems only arises for low-symmetry and high
number of
magnetic elements. I didn't have such problems before and I wonder
if we
could still use old mixer scheme in such situations. Looking at the
userguide, it seems that the mixer does not allow to do as before and
PRATT mixer is too slow.

Did you encounter similar difficulties (which were not in older WIEN2k
versions)?

Best Regards

Xavier

Here is the case.struct:

blebleble
P   LATTICE,NONEQUIV.ATOMS: 16 1_P1
MODE OF CALC=RELA unit=bohr
  14.167163  6.46 11.993298 90.00 95.267000 90.00
ATOM  -1: X=0.8750 Y=0.7500 Z=0.8750
   MULT= 1  ISPLIT= 8
Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
LOCAL ROT MATRIX:1.000 0.000 0.000
  0.000 1.000 0.000
  0.000 0.000 1.000
ATOM  -2: X=0.1250 Y=0.2500 

Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Laurence Marks]

N.B., in the 16 version if you reduce the GREED to 0.1 it does what people
think reducing the mixing factor does (in the unwritten literature). It
does not do it the way people think, this there are many misconceptions in
the literature about mixing. The latest version does this by turning on a
set of internal switches such as SLOW so it is less greedy. This may help
with your problem.

On Fri, Jan 20, 2017 at 3:16 PM, Laurence Marks 
wrote:

> I can provide some partial responses, although there are also some things
> that I don't understand. Some of this (maybe most) is not the mixer but in
> other parts of Wien2k.
>
> First, the old (2008) version is there if you use MSEC1, but I have not
> tested it and it may fail. Better is to use MSEC3 which is almost the old
> version. For some classes of problems this is more stable than MSR1, and
> works better. If you are talking about the pre-multisecant version (BROYD)
> that vanished some time ago.
>
> Second, there is a nasty "feature" particularly for +U (eece) cases, which
> is partially discussed in the mixer Readme. There is no guarantee that a
> solution exists -- the KS theorem is for densities but U is an orbital
> term. It is very possible to have cases where there is no fixed-point
> solution. The older MSEC1 (maybe BROYD) could find a fake solution where
> the density was consistent but the orbital potential was not. The latest
> version is much better in avoiding them and going for "real" solutions
> rather than being trapped. For orbital potentials it is very important to
> look at :MV to check that one really has a self-consistent orbital
> potential.
>
> Third, there are cases where PBE (and all the GGA's in Wien2k that I have
> tested) give unphysical results when applied to isolated d or f electrons
> as done for -eece. I guess that the GGA functionals were not designed for
> the densities of just high L orbitals. This leads to very bad behavior of
> the mixing. I know of no way to solve this in the mixer, it is a structural
> problem. It goes away if LDA is used as the form for VXC in -eece.
>
> Fourth, larger problem with low symmetry (P1 in particular) can certainly
> behave badly. Part of this might be "somewhere" in Wien2k coding, part of
> it is generic to a low symmetry problem. In many cases these have small
> eigenvalues in the mixing Jacobian which are removed when symmetry is
> imposed. All one can do is use MSEC3 or some of the additional flags (see
> the mixer README) such as "SLOW".
>
> Fifth...probably exists, but I can't think of it immediately.
>
> On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte <
> xavier.rocquefe...@univ-rennes1.fr> wrote:
>
>> Dear Colleagues
>>
>> I did recently a calculation which has been published long time ago
>> using a old WIEN2k version (in 2008).
>>
>> It corresponds to a spin-polarized calculation for the compound CuO. The
>> symmetry is removed and the idea is to estimate the total energies for
>> different magnetic orders to extract magnetic couplings from a mapping
>> analysis. Such calculations were converging fastly without any trouble
>> in 2008.
>>
>> Here I have started from the scratch with a case.cif file to generate
>> the case.struct file and initializing the calculation in a standard
>> manner.
>>
>> Then I wanted to have the energy related to a ferromagnetic situation
>> (not the more stable). I have 8 copper sites in the unit cell I am using.
>>
>> When this calculation is done using PBE+U everything goes fine. However
>> when PBE0 hybrid on-site functional is used we observed oscillations and
>> the magnetic moment disappear, which is definitely not correct. It
>> should be mentionned that the convergency is really bad. If we do a
>> similar calculation on the cristallographic unit cell (2 copper sites
>> only) the calculations converge both in PBE+U and PBE0.
>>
>> The convergency problems only arises for low-symmetry and high number of
>> magnetic elements. I didn't have such problems before and I wonder if we
>> could still use old mixer scheme in such situations. Looking at the
>> userguide, it seems that the mixer does not allow to do as before and
>> PRATT mixer is too slow.
>>
>> Did you encounter similar difficulties (which were not in older WIEN2k
>> versions)?
>>
>> Best Regards
>>
>> Xavier
>>
>> Here is the case.struct:
>>
>> blebleble
>> P   LATTICE,NONEQUIV.ATOMS: 16 1_P1
>> MODE OF CALC=RELA unit=bohr
>>   14.167163  6.46 11.993298 90.00 95.267000 90.00
>> ATOM  -1: X=0.8750 Y=0.7500 Z=0.8750
>>MULT= 1  ISPLIT= 8
>> Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
>> LOCAL ROT MATRIX:1.000 0.000 0.000
>>   0.000 1.000 0.000
>>   0.000 0.000 1.000
>> ATOM  -2: X=0.1250 Y=0.2500 Z=0.6250
>>MULT= 1  ISPLIT= 8
>> Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0

Re: [Wien] Mixer surprise when using PBE0 hybrid on-site functional

[Laurence Marks]

I can provide some partial responses, although there are also some things
that I don't understand. Some of this (maybe most) is not the mixer but in
other parts of Wien2k.

First, the old (2008) version is there if you use MSEC1, but I have not
tested it and it may fail. Better is to use MSEC3 which is almost the old
version. For some classes of problems this is more stable than MSR1, and
works better. If you are talking about the pre-multisecant version (BROYD)
that vanished some time ago.

Second, there is a nasty "feature" particularly for +U (eece) cases, which
is partially discussed in the mixer Readme. There is no guarantee that a
solution exists -- the KS theorem is for densities but U is an orbital
term. It is very possible to have cases where there is no fixed-point
solution. The older MSEC1 (maybe BROYD) could find a fake solution where
the density was consistent but the orbital potential was not. The latest
version is much better in avoiding them and going for "real" solutions
rather than being trapped. For orbital potentials it is very important to
look at :MV to check that one really has a self-consistent orbital
potential.

Third, there are cases where PBE (and all the GGA's in Wien2k that I have
tested) give unphysical results when applied to isolated d or f electrons
as done for -eece. I guess that the GGA functionals were not designed for
the densities of just high L orbitals. This leads to very bad behavior of
the mixing. I know of no way to solve this in the mixer, it is a structural
problem. It goes away if LDA is used as the form for VXC in -eece.

Fourth, larger problem with low symmetry (P1 in particular) can certainly
behave badly. Part of this might be "somewhere" in Wien2k coding, part of
it is generic to a low symmetry problem. In many cases these have small
eigenvalues in the mixing Jacobian which are removed when symmetry is
imposed. All one can do is use MSEC3 or some of the additional flags (see
the mixer README) such as "SLOW".

Fifth...probably exists, but I can't think of it immediately.

On Fri, Jan 20, 2017 at 2:03 PM, Xavier Rocquefelte <
xavier.rocquefe...@univ-rennes1.fr> wrote:

> Dear Colleagues
>
> I did recently a calculation which has been published long time ago
> using a old WIEN2k version (in 2008).
>
> It corresponds to a spin-polarized calculation for the compound CuO. The
> symmetry is removed and the idea is to estimate the total energies for
> different magnetic orders to extract magnetic couplings from a mapping
> analysis. Such calculations were converging fastly without any trouble
> in 2008.
>
> Here I have started from the scratch with a case.cif file to generate
> the case.struct file and initializing the calculation in a standard manner.
>
> Then I wanted to have the energy related to a ferromagnetic situation
> (not the more stable). I have 8 copper sites in the unit cell I am using.
>
> When this calculation is done using PBE+U everything goes fine. However
> when PBE0 hybrid on-site functional is used we observed oscillations and
> the magnetic moment disappear, which is definitely not correct. It
> should be mentionned that the convergency is really bad. If we do a
> similar calculation on the cristallographic unit cell (2 copper sites
> only) the calculations converge both in PBE+U and PBE0.
>
> The convergency problems only arises for low-symmetry and high number of
> magnetic elements. I didn't have such problems before and I wonder if we
> could still use old mixer scheme in such situations. Looking at the
> userguide, it seems that the mixer does not allow to do as before and
> PRATT mixer is too slow.
>
> Did you encounter similar difficulties (which were not in older WIEN2k
> versions)?
>
> Best Regards
>
> Xavier
>
> Here is the case.struct:
>
> blebleble
> P   LATTICE,NONEQUIV.ATOMS: 16 1_P1
> MODE OF CALC=RELA unit=bohr
>   14.167163  6.46 11.993298 90.00 95.267000 90.00
> ATOM  -1: X=0.8750 Y=0.7500 Z=0.8750
>MULT= 1  ISPLIT= 8
> Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
> LOCAL ROT MATRIX:1.000 0.000 0.000
>   0.000 1.000 0.000
>   0.000 0.000 1.000
> ATOM  -2: X=0.1250 Y=0.2500 Z=0.6250
>MULT= 1  ISPLIT= 8
> Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
> LOCAL ROT MATRIX:1.000 0.000 0.000
>   0.000 1.000 0.000
>   0.000 0.000 1.000
> ATOM  -3: X=0.1250 Y=0.2500 Z=0.1250
>MULT= 1  ISPLIT= 8
> Cu NPT=  781  R0=0.5000 RMT=1.9700   Z: 29.0
> LOCAL ROT MATRIX:1.000 0.000 0.000
>   0.000 1.000 0.000
>   0.000 0.000 1.000
> ATOM  -4: X=0.8750 Y=0.7500 Z=0.3750
>MULT= 1  ISPLIT= 8
> Cu NPT=  781