Dear all,
which is the correct way of using “restartxf” in order to continue a molecular dynamics (MD) simulation using several runs, each of them starting from the last step of the previous one? I'm using either ionmov 6 = Molecular dynamics using the Verlet algorithm, or ionmov 9 = Langevin MD, with abinit6.10.3, and my system is a single aminoacid surrounded by 20 water molecules (starting conformation extracted from classical MD trajectory).
Following the parallel MD tutorial, http://www.abinit.org/documentation/hel ... oldyn.html, i left the .in file unchanged, except for adding restartxf -1 starting from the second run.... and of course renaming the HIST file if i renamed the .in file for run n (n>1). ird/get den/wfk all set to zero.
Looking at the potential energy and kinetic energy for the NVE simulation (ionmov 6), it seems something bad is happening. I'm attaching the plots of: potential energy = converged ETOT_scf, kinetic energy = “Kinetic energy of ions”, both extracted from the .log file at the end of each MD step, vs time. I put a vertical line to indicate the end of run1. I'm also attaching the .in file for run2.
If i don't use restartxf in run2, Epot does not “explode”, but of course Ek starts again from zero in the second run, because abinit does not read velocities etc from the previous run, but only the coordinates xcart from the .in file. So in this case i understand what abinit is doing, but that's not what i would like to do in a multi-run MD simulation.
In Langevin simulations (ionmov 9), instead, Epot is again “jumping” going from run(n) to run(n+1), but Ek does not show any pathological behaviour: it just fluctuates as it should do in this kind of simulation.
The abinit tutorial,
http://www.abinit.org/documentation/hel ... #restartxf, warns “You can use restartxf=-1 or -2 for all predictors that make no use of random numbers”: this might be an explanation of my problem (?).. but in the parallel MD tutorial, restartxf seems to be used, for a simulation with ionmov 12.
In which types of MD simulation, i.e. for which values of ionmov, can one safely use restartxf -1 ? and... what to do in the other cases? Has anyone found a similar behaviour in multi-run MD simulations? Just to exclude problems related to wrong input keywords... (then of course i'm left with all possible problems due to starting structure etc)
Many thanks in advance
best
Elena Molteni
Department of Physics
University of Milan
via Celoria, 16
I-20133, Milan, Italy
and European Theoretical Spectroscopy Facility (ETSF)
http://www.etsf.eu
[SOLVED] restartxf for MD
Moderator: bguster
[SOLVED] restartxf for MD
- Attachments
-
- Epot_snp4_mdv_dt10_222st.ps
- potential energy vs time
- (18.62 KiB) Downloaded 253 times
-
- Ek_snp4_mdv_dt10_222st.ps
- kinetic energy vs time
- (18.44 KiB) Downloaded 214 times
-
run2.in
- run2 input file
- (5.36 KiB) Downloaded 230 times
Last edited by elena.mol on Wed Mar 06, 2013 10:32 am, edited 1 time in total.
Re: restartxf for MD
Hi,
it seems the problem and its solution were quite trivial.....
In my runs where the energy showed strange jumps, i had used a run2.in with restartxf -1, and xcart = the coords from the last step of run1.
It seems that using restartxf -1 and initial coordinates in run2.in, i.e. the same coordinates used in run1.in, is enough to avoid the above mentioned strange behaviour. (in fact i should have understood it when reading the parallel MD tutorial: "In tmoldyn_01.in add the keyword restartxf and set it to -1" really means "use the same input file as for the previous run, except for restartxf" .....)
sorry for the not-so-useful post
best
Elena Molteni
Department of Physics
University of Milan
via Celoria, 16
I-20133, Milan, Italy
and European Theoretical Spectroscopy Facility (ETSF)
http://www.etsf.eu
it seems the problem and its solution were quite trivial.....
In my runs where the energy showed strange jumps, i had used a run2.in with restartxf -1, and xcart = the coords from the last step of run1.
It seems that using restartxf -1 and initial coordinates in run2.in, i.e. the same coordinates used in run1.in, is enough to avoid the above mentioned strange behaviour. (in fact i should have understood it when reading the parallel MD tutorial: "In tmoldyn_01.in add the keyword restartxf and set it to -1" really means "use the same input file as for the previous run, except for restartxf" .....)
sorry for the not-so-useful post
best
Elena Molteni
Department of Physics
University of Milan
via Celoria, 16
I-20133, Milan, Italy
and European Theoretical Spectroscopy Facility (ETSF)
http://www.etsf.eu