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

2017-01-20 Thread 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

2017-01-20 Thread 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

2017-01-20 Thread 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  

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

2017-01-20 Thread Xavier Rocquefelte

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  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  -5: X=0.6250 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  -6: X=0.3750 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  -7: X=0.3750 Y=0.7500 Z=0.3750
  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  -8: X=0.6250 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  -9: X=0.8750 Y=0.4184 Z=0.6250
  MULT= 1  ISPLIT= 8
O  NPT=  781  R0=0.0001 RMT=1.6900   Z: 8.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM -10: X=0.1250 Y=0.9184 Z=0.8750
  MULT= 1  ISPLIT= 8
O  NPT=  781  R0=0.0001 RMT=1.6900   Z: 8.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM -11: X=0.1250 Y=0.5816 Z=0.3750
  MULT= 1  ISPLIT= 8
O  NPT=  781  R0=0.0001 RMT=1.6900   Z: 8.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000