[Q-e-developers] relaxations - final scf and magnetism

[Paolo Giannozzi]

Hi Nicolas, thank you for your report and proposal. The last scf step
in a variable-cell optimization is a never-ending source of trouble.
The ultimate fix for your problem is to restart from data at the
previous step, but this would require some serious work.

Paolo

On Sun, Feb 12, 2017 at 6:05 PM, Nicolas Mounet <nicolas.mounet at epfl.ch> wrote:
> Dear all,
>
> I would have a tentative improvement for the final scf of a relaxation done
> with pw.x, following an issue I encountered on magnetic materials.
>
> The issue is that sometimes, on a magnetic system, after making a few scf
> loops that converged nicely, the last final scf calculation, on the
> contrary, would not converge, or much more slowly. After investigation it
> seemed to me that the reason was that the final magnetic moments (at the end
> of the bfgs loop) were relatively far from the initial starting
> magnetization, which the final scf still uses, thus spoiling the initial
> magnetic moments of the last scf loop.
> Most of the time, it does not matter too much because the code converges
> back easilly to the correct magnetic moments. But in some cases, it prevents
> the final scf from converging, or makes it converge to a wrong magnetic
> ground state, or simply adds a significant number of scf iterations compared
> to the previous bfgs steps.
>
> My solution is, in the PW/src/move_ions.f90 subroutine (in the part
> launching a final scf), to re-initialize the starting magnetizations from
> the magnetic moments obtained at the last bfgs step, using the get_locals
> function (imitating what's done in report_mag), and re-launching the full
> setup (note that I imitated what's done in run_pwscf.f90 for the
> initialization - I'm not 100% sure about the usefulness of the call to
> qmmm_update_positions at this stage).
>
> I attached my modified move_ions.f90 routine here (modified from the current
> GIT version of this morning - 12/02/2017). I also adapted it to the
> spin-orbit coupling calculation. I tested it on two systems: a quite
> pathologic (and far from convergence) Ho crystal (final scf is not
> converging in 100 iterations in the initial version, and converges in 55
> iterations with the modification), and a much less pathologic and normally
> better converged AlFe one (final scf: 22 iterations in the initial version,
> 13 with the modification). For the latter one I also tried with spin-orbit
> coupling. I attach here inputs and outputs (outputs with 'git' in the name
> means it's the current git version, 'modif' is obtained with the modified
> move_ions subroutine). To me everything seems to work as expected: the
> change seems to help to get a better magnetic initial state at the beginning
> of the last scf loop.
>
> I also did more tests (e.g. taking away the starting magnetization on AlFe -
> with and without SOC); I already used the code in almost high-throughput
> mode for different kind of systems (magnetic and non-magnetic). No bad
> surprises so far - in cases "without problem" with the unmodified code, the
> final scf can have a slightly different number of iterations with the
> modification (in better or worse), but nothing dramatic.
>
> Let me know what you think, I might well have overlooked some aspects of the
> problem.
>
> As a side remark, in the same routine I noticed that the threshold for
> detecting if a material has zero absolute magnetization and should therefore
> be re-run without any magnetic history (the opposite case as the one I
> treated in my modification - I did not change this part), is very small
> (eps6 in the code, i.e. 10^-6). For example, on a Si crystal I obtained a
> final absolute magnetization of a few 10^-5, in a spin-polarized
> calculation. But I did not make lots of tests playing with this threshold,
> so in the end I did not change anything yet in that respect.
>
> sorry for the very long post...
>
> best regards,
> Nicolas
>
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers
>



-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222