[Q-e-developers] relaxations - final scf and magnetism
Nicolas Mounet
nicolas.mounet at epfl.ch
Sun Feb 12 18:05:10 CET 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: move_ions.f90
Type: text/x-fortran
Size: 17845 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20170212/32c8bcd2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AlFe_Ho_tests.tar.gz
Type: application/x-gzip
Size: 836584 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20170212/32c8bcd2/attachment-0001.bin>
More information about the developers
mailing list