[Wien] initso - convergence jump after reduction of symmetry

[Peter Blaha]

We recently fixed one problem in SRC_symmetso connected with the 
reduction of symmetry and splitting of equivalent atoms into 
no-equivalent ones.

Replace clmchange.f  with the attached file and recompile.

Regards

On 05/18/2015 01:36 PM, Vojtech Chlan wrote:
> 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 at 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

-- 

                                       P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300             FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at    WIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clmchange.f
Type: text/x-fortran
Size: 5468 bytes
Desc: not available
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20150518/4a9baaf0/attachment.f>