[Wien] Three questions
Laurence Marks
L-marks at northwestern.edu
Wed Sep 19 15:24:23 CEST 2018
As an addendum, the only cases I know of when PRATT is relevant are:
1. With mBJ at the start (although I wonder about this)
2. With really badly posed problems, although it may not be safe and
even then should only be used for a few iterations
3. In some cases "echo 0.025 > .pratt" may be useful in a poorly
converging problem to add a single Pratt step and/or to disrupt a series of
poorly converging steps. The value "0.025" may need adjustment, it should
not in most cases be significantly larger than the recent *GREED* values.
Adding PRATT to the bottom of case.inm (in more recent versions) is better,
but not great. In some cases changing from MSR1 to MSEC3 may help with
poorly converging problems.
However, there are no indications that any of this is relevant to this -so
case.
In most cases the mixer in 18.1 is smarter than you are. I think the next
mixer (10.2) is smarter than I am, although it does not handle
pseudo-charge issues well (an ongoing issue). No mixer will ever handle
poorly posed and very badly conditioned problems when the KS equations do
not have a solution or are very noisy -- no free lunch.
On Wed, Sep 19, 2018 at 7:43 AM, Laurence Marks <L-marks at northwestern.edu>
wrote:
> You may you have soft modes, i.e. quite large changes in the wavefunction
> lead to only small changes in the energy. This can occur, for instance, if
> the changes due to spin-orbit are small. In these cases energy convergence
> (-ec) is not a good metric and charge convergence (-cc) needs to be tight.
>
> In general you should not simply look at the energy convergence, but at
> other terms. There is a utlility "Check-mixing" which gives much more
> information. An example of the output is:
>
> :DIS : CHARGE DISTANCE ( 0.0000612 for atom 1 spin 2)
> 0.0002222
> :MVORD NDM 200 L1 2.007523E-06 % 2.9580E-03
> :PLANE: PW TOTAL 4.3137 DISTAN 1.80E-04 4.18E-03 %
> :CHARG: CLM/ATOM 87.5667 DISTAN 7.90E-05 9.02E-05 %
> :RANK : ACTIVE 6.59/8 = 82.33 % ; YY RANK 6.30/8 = 78.75 %
> :DIRM : MEMORY 8/8 SCALE 1.000 0.899 RED 0.54 PRED 0.64 NEXT 0.51
> :DIRD : |MSR1|= 7.016E-04 |PRATT|= 3.608E-04 ANGLE= 12.5 DEGREES
> :DIRP : |MSR1|= 1.030E-04 |PRATT|= 9.014E-05 ANGLE= 11.8 DEGREES
> :DIRQ : |MSR1|= 3.666E-04 |PRATT|= 2.370E-04 ANGLE= 29.0 DEGREES
> :DIRT : |MSR1|= 7.982E-04 |PRATT|= 4.410E-04 ANGLE= 19.3 DEGREES
> :MIX : MSD1 REGULARIZATION: 2.50E-04 GREED: 0.35000 Newton 1.00
> 1.8102
> :ENE : ********** TOTAL ENERGY IN Ry = -6383.89763604
>
> Notes on the different lines:
>
> *DIS:* This is the charge convergence used in -cc
> *MVORD:* This is the convergence of orbital potential terms (+U or -eece)
> *PLANE:* This is the convergence of the interstitial density
> *CHARG:* This is the convergence of the density inside the RMTs
> *RANK:* This measures how independent the memory directions are. Ideally
> it should be large.
> *DIRM:* Shows the latest provement versus what was expected and what is
> predicted for the next iteration
> *DIRD:* Shows the latest step size for the orbital term, the Pratt value
> and the angle between them
> *DIRP:* The same as *DIRD:* for the plane waves
> *DIRQ:* The same for the density inside the RMT
> *DIRA:* The same for the atoms (not shown in the example)
> *DIRT:* The sum of the above
> *MIX:* The regularization, *GREED,* how large the step was and
> information about the Trust size
>
> *Things to watch:*
>
> 1. All of *DIS, MVORD, PLANE, CHARG* should be small for a
> well-converged case
> 2. Small values of *RANK* may indicate a problem with the physical
> model
> 3. Ideally *DIRM* should show reasonable reduction (0.7-0.9). It may
> jump around a bit, not a problem
> 4. The angles in *DIRD, DIRA, DIRP, DIRQ, DIRT* should not be near 90.
> If they are consistently this means that the physical problem may not be
> well posed or is ill-conditioned
> 5. Large values the the step (right) in *MIX* are not a problem, but
> indicate the presence of soft modes
> 6. With the 18.1 mixer small values of *GREED* are fine. In earlier
> versions they may indicate a problem
> 7. Small values on the right of *MIX* with the trust region remaining
> active for many iterations may indicate a problem with the physical model.
>
>
> On Wed, Sep 19, 2018 at 7:16 AM, Lukasz Plucinski <
> pluto at physics.ucdavis.edu> wrote:
>
>> Dear Prof. Blaha, dear All,
>>
>> I tried what you have suggested and still have some problems.
>>
>> Could you describe the second symmetry in struct file:
>>
>> 2 NUMBER OF SYMMETRY OPERATIONS
>> 1 0 0 0.00000000
>> 0 1 0 0.00000000
>> 0 0 1 0.00000000
>> 1 A 1 so. oper. type orig. index
>> -1 0 0 0.00000000
>> 0-1 0 0.00000000
>> 0 0 1 0.00000000
>> 2 B 3
>>
>> Is that generic for SOC?
>>
>> For a series of angles (say every 5 degrees) the results for same angles
>> are "off", one can see it clearly from plotting 2D sheets of bands,
>> since they e.g. exhibit Weyl points that "move around" when M direction
>> is changed.
>>
>> What is strange is, that increasing the convergence criteria from -ec
>> 0.0001 -cc 0.001 to -ec 0.0001 -cc 0.0001 may lead to quite dramatic
>> changes, while keeping everything else intact.
>>
>> I tried -fermit 0.004, that again leads to very different dispersions
>> for some bands. Now I am trying -fermit 0.00074 (10 meV). I am using
>> RKmax 7.5, that should be fine, but maybe I should increase to 9?
>>
>> Perhaps there is some issue with the default mixer? Sometimes it takes
>> many iterations to converge for some M angles, while only few for other
>> M angles. I am now testing with the PRATT setting, maybe it will be more
>> consistent.
>>
>> Maybe you could advice what else can be tried.
>>
>> Best,
>> Lukasz
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 9/10/2018 11:49 AM, Peter Blaha wrote:
>> >
>> >> 1. CHARGE CONVERGENCE: I know this has been discussed before, but it
>> >> seems it didn't change in Wien2k_18. Here is a typical example of the
>> >> charge convergence history of the last few iterations of FM+SOC
>> >> (ferromagnetic + spin orbit coupling) calculation:
>> >>
>> >> :ENERGY convergence: 0 0.0001 .0001320450000000
>> >> :CHARGE convergence: 0 0.001 .0027578
>> >> :ENERGY convergence: 1 0.0001 .0000497650000000
>> >> :CHARGE convergence: 0 0.001 .0050904
>> >> :ENERGY convergence: 1 0.0001 .0000557650000000
>> >> :CHARGE convergence: 0 0.001 .0004672
>> >> :ENERGY convergence: 1 0.0001 .0000220050000000
>> >> :CHARGE convergence: 1 0.001 -.0001786
>> >>
>> >> Something strange happens with charge convergence, is this OK?
>> >
>> > This is ok.
>> >
>> >
>> >> 2. LIMITS in inso and in1c files: in order to avoid large vector
>> >> files I am changing the energy limits in inso and in1c files for band
>> >> structure calculations. SCF is done with default inso and in1c files,
>> >> then I do save_lapw, then I edit case.inso and case.in1c files, and
>> >> then I do FM+SOC band structure calculation:
>> >>
>> >> #! /bin/bash
>> >> x lapw1 -band -up -p
>> >> x lapw1 -band -dn -p
>> >> x lapwso -up -p
>> >>
>> >> I am using emin/emax -0.5 0.5 in both files (inso and in1c) without
>> >> changing anything else, then I have bands from limited energy range.
>> >> I just want to make sure that this procedure is fine.
>> >
>> > No, this is NOT ok. You must not change Emax in case.in1c !
>> > If you do, your basis set for the spin-orbit step is limited and
>> > eigenvalues will change as compared to the scf calculation.
>> > You can reduce emax in case.inso if you are not interested in the
>> > bands at higher energies.
>> >
>> >
>> >> 3. FM+SOC convergence: I am doing FM+SOC calculations for different
>> >> in-plane magnetization M directions in a 2D Fe(001) ferromagnetic
>> >> layer. Actually an older Wien2k_14 version was not working well for
>> >> this, results for generic M directions were really strange. Wien2k_18
>> >> seems much better, however, when starting things from the scratch
>> >> (each M angle completely separate calculation) it seems that for some
>> >> M angles the result is off, as if it didn't actually properly
>> >> converge. I am using a fairly dense mesh for SCF (2000k, 25 25 3),
>> >> and -ec 0.0001 -cc 0.001. Should I maybe try -fermit setting in
>> >> init_lapw, and what would be a reasonable value? Do I always need to
>> >> use instgen_lapw before init_lapw when starting a new case? Should I
>> >> perhaps do each next M angle on top of a previously converged M angle
>> >> (and save_lapw for each M angle)?
>> >
>> > Doing separate calculations for different directions may / may not
>> > yield correct results.
>> > The proper (save) way is to use ONE case.struct file for all cases.
>> > i) select all directions of magnetization first.
>> > ii) Produce (using init_so) struct files, which are the same for all
>> > cases (do not change after init_so) and use this struct file for ALL
>> > (also non-so) calculations.
>> > This works as:
>> > a) generate normal struct file.
>> > b) init -b -sp ....
>> > c) init_so with first direction, accept the generated structure
>> > d) init_so with second direction, accept ...
>> > repeat this for all desired directions (or until you have a P1
>> > structure (only identity).
>> >
>> > e) with this setup (no new init_lapw !!!!) execute:
>> > runsp -ec ... and save as "non-so"
>> > runsp -so ... and save as "so-dir_2"
>> > restore non-so; edit case.inso and put the first direction in;
>> > runsp -so ... and save as "so-dir_1"
>> >
>> > In this way, you can also compare the force-theorem (:SUM of first
>> > iteration (2 numbers !) with the scf solution.
>> >
>> >
>> >
>> >>
>> >>
>> >> Best,
>> >> Lukasz
>> >> _______________________________________________
>> >> Wien mailing list
>> >> Wien at zeus.theochem.tuwien.ac.at
>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.the
>> ochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04Hh
>> Braes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8I
>> Uxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISE
>> bNoz-BU&s=byttKcG3fB5SX8X14AmraL5--3cw8SzUW-gmgSoGSjQ&e=
>> >> SEARCH the MAILING-LIST at:
>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail
>> -2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html&
>> d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_
>> T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2
>> r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=U-JugXVpg9xrhWWaGTwEXn7_zCiZXa
>> 6CwtdW5ntg2bI&e=
>> >
>>
>> _______________________________________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.the
>> ochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04Hh
>> Braes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8I
>> Uxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISE
>> bNoz-BU&s=byttKcG3fB5SX8X14AmraL5--3cw8SzUW-gmgSoGSjQ&e=
>> SEARCH the MAILING-LIST at: https://urldefense.proofpoint.
>> com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.the
>> ochem.tuwien.ac.at_index.html&d=DwIGaQ&c=yHlS04HhBraes5BQ9ue
>> u5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvq
>> KFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=
>> U-JugXVpg9xrhWWaGTwEXn7_zCiZXa6CwtdW5ntg2bI&e=
>>
>
>
>
> --
> 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
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20180919/543618cb/attachment-0001.html>
More information about the Wien
mailing list