[Wien] initso - convergence jump after reduction of symmetry

[novakp at fzu.cz]

Dear Vojta,

I encountered the problem you describe several times, tried to find the
remedy and failed. The only unpleasant way which works is to start the
calculation from scratch with reduced symmetry. Other possibility would be
after converging the calculation rotate the density to local system of
newly nonequivalent atoms. This would, however, require some programming.

Regards Pavel

> 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
>

 
--  
Upozorneni: Neni-li v teto zprave vyslovne uvedeno jinak, neni tato e-mailova zprava navrhem na uzavreni smlouvy ani prijetim pripadneho navrhu na uzavreni smlouvy a nezaklada predsmluvni odpovednost FZU AV CR, v.v.i.
Disclaimer: If not expressly stated otherwise, this e-mail message cannot be considered as a proposal to conclude a contract, neither the acceptance of a proposal to conclude a contract, nor does it create any pre-contractual liability on the part of FZU AV CR, v.v.i.