Dear WIEN2k community,
I am facing a problem with disturbance of convergence when the symmetry
of the structure is lowered (e.g., by initso_lapw).
It is well known in spin-polarized calculations that introducing the
spin-orbit interaction may reduce symmetry - in dependence on whether
the chosen direction of magnetization is compatible with present
elements of symetry or not. In spin-polarized cases where the symmetry
is not reduced, e.g. uniaxial structure with magnetization parallel to
the axis, the process is usually quite smooth: After well converged
runsp_lapw and initso call, the subsequent "runsp_lapw -so" calculation
starts almost converged and usually converges within a few iterations
(at least when no really heavy elements are present so that the
spin-orbit coupling is rather weak).
However in cases where the symmetry is reduced during initso (symmetso),
the continuation by runsp_lapw -so is not so smooth. According to my
experience there is often a substantial jump in the charge distance, the
magnetic moment may start to collapse etc. In fact, the jump in
convergence is present regardless the -so switch (or other parameters
that are usually changed during initso, e.g., Emax).
To illustrate this behaviour I did a few tests on barium hexagonal
ferrite (SG #194, P63/mmc):
Firstly, it was fully converged with quite standard parameters - using
PBE-GGA+U (U=4.5eV, J=0), with RKM=6.0, 100 k-points; wien version 14.2
was used.
Now, since there is the hexagonal axis (direction 001), starting initso
and setting the magnetization in 001 naturally does not reduce symmetry.
As expected, everything is nice and smooth when one starts runsp_lapw
-so .... there is only :DIS = 0.015 in the first iteration and the
calculation converges within a few iterations.
But when I set magnetization in direction 100, which kills half of the
symmetry operations (and 11 non-equivalent atoms become 15), the first
iteration starts with a jump in :DIS = 2.31. The -so switch is
irrelevant, the jump is there even for runsp_lapw without the -so switch.
My (naive) understanding of the origin of this jump is that it arises
from the change of basis for those atom sorts that became nonequivalent.
The inclusion of magnetization reduces also the local point group
symmetries of atoms (also often accompanied by change in rotation
matrices), which sumsequently changes their lists of LM expansions in
case.in2 file. The increase of LMs in expansion then manifests after
first iteration also in CLM files and one gets a jump in convergence.
When such changes concern only a few atoms in the structure or the
change in basis is small, it seems the calculation can often be
converged despite the jump. However when more and more atoms have their
expansions changed the jump becomes higher, eventually, for large
structures and in cases where the magnetization strips the structure of
almost all symmetries the jump becomes irrecoverable: the calculations
(with or without -so) crash typically in second iteration (when the new
LMs are first mixed) or even in first (in SELECT), in some cases the
runs survive without a crash but the potentials go all crazy and for
example magnetic moments collapse (anyway the convergence fails). I have
partially learned to live with that and partially learned to circumvent
this by reducing the symmetry not all at once, but in steps (and
re-converge in between) and by using other tricks to avoid crash and
maintain convergence. However, currently I try to switch on the
spin-orbit in a system too large where this simply does not help.
I can be all wrong, blaming the change in LMs, but I could not find any
other cause for the jump. And I believe I cannot touch the LM expansions
as they are given by the point group symmetry of the site.
I made a few naive attempts to fool some routines (mixer, clmextrapol)
into translating the clm files into ones with a new set of LMs, but
without proper knowledge of what I was doing, I naturally only ended up
with nonsenses and segmentation faults.
Is there any possibility to "smoothly renormalize" the density for a
changed set of LMs?
Well, perhaps I am blind to some completely different and obvious
solution, so any help would be appreciated.
Best regards
Vojtech
_______________________________________________
Wien mailing list
Wien@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