[Wien] Three questions
Peter Blaha
pblaha at theochem.tuwien.ac.at
Wed Sep 19 19:33:30 CEST 2018
Am 19.09.2018 um 15:24 schrieb Laurence Marks:
> 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)
With the latest mixer versions it is usually NOT recommended to use
PRATT with mBJ. Te mixer is now clever enough ....
> 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 <mailto: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 <mailto: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
> <mailto:Wien at zeus.theochem.tuwien.ac.at>
> >>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=byttKcG3fB5SX8X14AmraL5--3cw8SzUW-gmgSoGSjQ&e=
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-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=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=U-JugXVpg9xrhWWaGTwEXn7_zCiZXa6CwtdW5ntg2bI&e=
> <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=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=U-JugXVpg9xrhWWaGTwEXn7_zCiZXa6CwtdW5ntg2bI&e=>
> >
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> <mailto:Wien at zeus.theochem.tuwien.ac.at>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=byttKcG3fB5SX8X14AmraL5--3cw8SzUW-gmgSoGSjQ&e=
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-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=y6qDc2TcpaXRKpE2r7W0RjYxwIsoZ7mF0ISEbNoz-BU&s=U-JugXVpg9xrhWWaGTwEXn7_zCiZXa6CwtdW5ntg2bI&e=
> <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=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 <http://www.numis.northwestern.edu> ;
> Corrosion in 4D: MURI4D.numis.northwestern.edu
> <http://MURI4D.numis.northwestern.edu>
> Partner of the CFW 100% program for gender equity,
> www.cfw.org/100-percent <http://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 <http://www.numis.northwestern.edu> ;
> Corrosion in 4D: MURI4D.numis.northwestern.edu
> <http://MURI4D.numis.northwestern.edu>
> Partner of the CFW 100% program for gender equity,
> www.cfw.org/100-percent <http://www.cfw.org/100-percent>
> Co-Editor, Acta Cryst A
>
>
> _______________________________________________
> Wien mailing list
> Wien at 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
>
--
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at WIEN2k: http://www.wien2k.at
WWW:
http://www.imc.tuwien.ac.at/tc_blaha-------------------------------------------------------------------------
More information about the Wien
mailing list