[Pw_forum] Constrained magnetic calculation
gabriele.sclauzero at mat.ethz.ch
Wed Mar 5 10:38:05 CET 2014
I do not know if it make sense or not in general, anyway this
possibility is not available at the moment. All atoms of atomic type i
will be constrained to have local magnetization equal to
starting_magnetization(i). However, you can try to edit the magnetic
constraint subroutine in PW/src/add_bfield.f90 to suit your needs.
Materials Theory, ETH Zurich
On 03/05/2014 05:25 AM, Varadharajan Srinivasan wrote:
> Dear Gabriele,
> To add to Paresh's question is it possible (and does it make sense) to
> constrain the magnetisation of only a few atoms and not the others?
> While the target here seems to be atoms 3 and 4 the other atoms are
> being made to pay the price so to speak.
> One option, in the present framework, is to constrain the values of
> magnetisation of all other atoms to their respective lambda=0 values.
> Could this speed up the convergence with lambda?
> On Tue, Mar 4, 2014 at 7:18 PM, Gabriele Sclauzero
> <gabriele.sclauzero at mat.ethz.ch
> <mailto:gabriele.sclauzero at mat.ethz.ch>> wrote:
> What about the evolution of the constrained magnetization?
> (Please also make sure that the values specified in
> starting_magnetization make sense, as suggested by L. Paulatto Sir).
> My suggestion was to vary lambda in small steps (say 0.5). I'm
> surprised that you managed to converge the calculation with such
> high lambda values.
> Anyway, the constrain energy looks way too large, your system is
> probably still far from the target.
> On 03/04/2014 01:57 PM, paresh rout wrote:
>> Respected Sclauzero sir,
>> Thanks for your reply. According to your suggestion, I varied
>> my Lambda value from 0,5,.......150 ry. Although calculated
>> constrained energy are decreasing but upto 150 ry the constrained
>> energy and the estimated scf accuracy are not the same order.
>> Here I am providing my constrained energy with various lambda value.
>> Lambda Constraint_Energy
>> 0 0.00000000
>> 5 36.93411685
>> 10 69.54815816
>> 15 6.65653915 estimated scf accuracy < 7.6E-13 Ry
>> 20 7.88546052
>> 25 8.88385707
>> 30 9.71513061
>> 35 10.42697250
>> 40 11.05006563
>> 45 11.60072229
>> 50 12.08887057
>> 70 13.54966033
>> 80 14.05546257
>> 90 14.45159513
>> 100 14.75974550
>> 110 14.99680383
>> 120 15.17624003
>> 130 15.30876396
>> 140 15.40310437 estimated scf accuracy
>> < 9.9E-13 Ry
>> 150 15.46632278 estimated scf accuracy
>> < 9.9E-13 Ry
>> On Tue, Mar 4, 2014 at 3:06 PM, Sclauzero Gabriele
>> <gabriele.sclauzero at mat.ethz.ch
>> <mailto:gabriele.sclauzero at mat.ethz.ch>> wrote:
>> Dear Paresh,
>> in my understanding you should start with a very small
>> lambda value (e.g. 0.1), make sure the calculation has
>> converged (not always trivial), then restart with a larger value.
>> It is important to tune the steps by which you increase
>> lambda. Increasing it by steps of 5 seems too much to me, I
>> would suggest you to try much smaller steps, say between 0.1
>> and 0.5.
>> There are two reasons why the energy increases: the first is
>> because you are constraining your system out of its ground
>> state, but that's exactly what one would expect. The other is
>> the contribution from the penalty energy (E_constrain, it
>> should be printed after each scf step), which is used to
>> impose the constraint.
>> An important thing is that this energy term is not physical
>> and becomes negligible once your system reaches the target
>> state.Therefore one should monitor this constraint energy,
>> together with the constrained quantity, and make sure it goes
>> to zero at some point.
>> Once lambda is large enough and you reached the targeted
>> state, E_constrain should be negligible w.r.t. the total
>> energy and of the same order of the estimated scf accuracy.
>> From that point on, the energy should not change if you
>> further increase lambda, because your system fulfills
>> (almost) exactly the constraint, so that E_constrain should
>> stay to a very low value.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users