[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