The ABINIT Users Mailing List ( CLOSED )

[Jorge Iniguez <jiniguez@nist.gov>]

Dear abinitioners,

I have found the following problem.

First let me tell you what I get when I use HGH pseudos: Consider
vector-magnetization calculations (nspeden=4, nspinor=2) without
spin-orbit (for simplicity). It turns out that for magnetizations along x
and z (which we "set" with spinat) abinit works perfectly well. In fact,
one can nicely reproduce the result obtained with nsppol=2. However, for a
magnetization along y the calculation does not converge!!

I enclose the files test-hgh.in, test-hgh.out, and test-hgh.log,
corresponding to rough calculations for MnF2 in ferromagnetic spin
configurations. The three datasets correspond to magnetizations along the
three Cartesian directions. The results for x and z reproduce that of the
nsppol=2 calculation (see enclosed file test-hgh-nsppol2.out). The problem
for the y direction (dataset # 2, which is calculated in the third place)
is apparent. The program seems to approach the right solution but it does
not get to converge and, after 59 steps, it decides to stop
(``Potential-based CG line minimization not converged after 13
restarts.'')

((By the way: The lines in the output and log files that start with ``3D
magnetization'' report the value of the magnetization vector, and are
useful to make sure that spinat works. These are written by our local
version of abinit. Apart from that, the log and output files should be
reproducible.))

I also enclose results for the same calculations but using
Troullier-Martins pseudos (files test-tm.out and test-tm-nsppol2.out). The
x and z cases both converge in 23 steps, while it takes 32 steps for the y
case to converge. Other tests I have done indicate this is not a
coincidence.

I have looked into the code but have not been able to find the cause of
the asymmetry between x and z (which are fine) and y. It occurs to me that
a magnetization along y is particular in the sense that it requires the
real part of the first spinor wave function to be related with the
imaginary part of the second (etcetera), which may make this case be more
sensitive to certain [coding mistakes? / numerical inaccuracies?] than the
x and z cases are??

Anyone can help with this?

Thanks,

Jorge


------------------------------------------------------------------------------
   Jorge Iniguez             Bldg 235, Room E19
                             NIST Center for Neutron Research
                             100 Bureau Drive, Mail Stop 8562
                             Gaithersburg, MD 20899-8562
                             Phone: 1-301-975-8367 Fax: 1-301-921-9847
                             E-mail address: jiniguez@nist.gov
                             http://www.ncnr.nist.gov/staff/jorge
------------------------------------------------------------------------------

Attachment: files.tar.gz
Description: Binary data