ABINIT Discussion Forums

Hello,
I am integrating the LOTF method in a recent version of ABINIT and I have some doubts
on the "correct way" to do things.
In the previous weeks I integrated LOTF in a old version of abinit (5.5) (this step was needed because
the old LOTF code was a long F77 file which I translated in a more modern F90).
Now passing to the new version of ABINIT and the new structure of MOVER procedure (scfcv+specialized predictor)
is giving me some trouble.

LOTF passes SCFCV 2 times at the first step (itime=1): the first is a normal cycle while in the second one it uses some extrapolated
atom positions to compute a set of parameters which will be used in the next steps.
The results of this second call to SCFCV should be not stored at all.
In the following steps (saying 10) the SCFCV should be shortcut.

From my point of view, the ideal and simpler, should be to integrate the call to SCFCV in the LOTF predictor as was done in 5.5 version.
Is it possible (ethically) to do it?

Best regards,
Marco

Hi Marco,

First of all, you should probably contact Guillermo Avendano (guillermo.avendano@uclouvain.be) who is the author of the mover and predictors routines.

Second point:
Reading your message, I'm wondering if the 2nd (not stored) call to scfcv could perturb the calculations.
From one call to scfcv to another, several quantitites are transmitted, mainly the density and the wave functions, and used in predictor algorithm using a scf_history datastructure.
They are used to start each SCF cycle. Your second call to scfcv could perturb this and make the first few calls to scfcv unefficient.
Is it possible to make this 2nd call to scfcv at first ?... and then to re-initialize everything (cd, rhor, ...) ?

Apparently, this second call to scfcv is the only difference between LOTF enad other predictors, right ?
If yes, you could just add this second call to your predict_lotf routine and let the other calls to scfcv in mover.
Is it your idea ?
Doing this, if really nothing is stored from the 2nd call to scfcv, you can imagine to create a fake scfcv_args datastructure inside predict_lotf, then call scfcv, keep the data you are interested in and destroy this fake scfcv_args...
Doing this, I think you keep the structure scfcv/predictor/hist intact...
But perhaps, I am missing one point and this idea is bad...

That's just a first idea...

The best,

Marc

Hello Marc,
thanks for your reply.
I contacted yet Guillermo and he is helping me.

I am sorry if my post is not very clear. Here a little schema which I hope will be more clear:

In the first step two GS are to be computed while for the following only one:
t=1) compute GS in t=1,
LOTF potential for t=1: alpha_in
from extrapolation, position at t=10 are computed
GS(t=10)
LOTF potential for t=10: alpha_out
t=2) no GS, but used the interpolated LOTF potential in the interval (a_in,a_out)
...
...
t=11) alpha_in=alpha_out;
from extrapolation, positions at t=20 are computed
GS(t=20)
LOTF potential for t=20: alpha_out
t=12) as t=2)
....

So the difference is not only in the first cycle but also in the other where GS is not computed
at the time t but on t+10. Then the position at t=n+10 where 1<=n<10 are computed by LOTF using intepolation.

Hi Marco,

OK I understand.
But this not so different...
You just have to call scfcv twice each 10 steps...

My ideas are still applicable for each of these steps (1, 11, 21, ...).
1) Have a correct management of cg, rhor, scf_history in order to help the SCF cycle to converge
(you should eliminate from the history the second call to scfcv done at steps 1, 11, 21...)
2) Hide the second call to scfcv in your predict_loft predictor and use temporary (fake) values for scfcv_args

If you do that, you can keep the current flowchart of mover.
Especially for 2), if you do that, you just consider that the second call to scfcv is a part of the predictor ; in fact, this the case, right ?

Hello Marc,
In the version of LOTF integrated in ABINIT 5.5 the "predictor" (in this cas was directly in MOLDYN.F90)
had a call to scfcv but now is seems that I can't do that: predictor can not contain scfcv.
DO you thing that I can do that?

Regards,
Marco

Hello Marc,
Ok I think that now it works!

I have not integrated the SCFCV in PRED_LOTF.
I have followed the suggestions that Guillermo and you given me.

when I have to do extrapolation at time t (any 10 steps for example), I set the number of ncycle=2
In the first cycle SCFCV computes the forces at time t (in the old method I didn't recompute this) and
the extrapolated position at t+10 (Storing the old position and velocities in local saved arrays)
Then the second cycle call SCFCV in the positions at t+10 (and the predictor restore the values for t):


t=1) icycle=1) compute GS in t=1,
predictor:
-LOTF potential for t=1: alpha_in
-Stored pos,vel (pos_old=pos,...)
-by extrapolation, position at t=10 are computed

t=1) icycle=2) compute GS in t=10,
predictor:
-LOTF potential for t=10: alpha_out
-restore pos,vel (pos=pos_old,... )
-new positions, new alpha for the next step (interpolation)
t=2) no GS, but used the interpolated LOTF potential in the interval (a_in,a_out)
...
...
t=11) icycle=1) as in 1)2)
t=11) icycle=2) as in 1)1)
t=12) as t=2)
....


In this way the algorithm is more symmetric and then simpler to integrate.

But I have still some doubts concerning the HIST file and MOLDYN.
Which is the more appropriate way to store my results in them?
If I leave as ABINIT do I have twice t=1,11... in HIST file but not in MOLDYN.
Which icycle is used by MOLDYN to store data (for me should be 1)?
I was looking in MOVER.F90 but, for me, it is not very simple to understand.

Best regards,
Marco