Sai Pooja wrote:
Thanks Justin for being so patient. I have understood almost everything
and I hope this is the last question on this thread.
See inline ...
On Wed, Feb 2, 2011 at 5:53 PM, Justin A. Lemkul <jalem...@vt.edu
<mailto:jalem...@vt.edu>> wrote:
Sai Pooja wrote:
On Wed, Feb 2, 2011 at 3:15 PM, Mark Abraham
<mark.abra...@anu.edu.au <mailto:mark.abra...@anu.edu.au>
<mailto:mark.abra...@anu.edu.au
<mailto:mark.abra...@anu.edu.au>>> wrote:
On 3/02/2011 6:15 AM, Sai Pooja wrote:
The problem is solved with grompp i.e. I use the -t .cpt
option.
However, now appending does not work. I remember Mark
said in a
previous mail that a certain environment variable can allow
appending to happen even in such cases. I would liek to
try that
out.
No, I said that an environment variable can override the
mechanism
that blocks ensemble changes in mdrun.
So how can I use this environment variable.. I might be asking
an absurd question since I don't really understand what an
environment variable is. But I would definitely liek to
experiment with it, since I am in the process of trying out
these different options and figuring out which would be the best.
http://en.wikipedia.org/wiki/Environment_variable
I think the pertinent one in this case is GMX_ALLOW_CPT_MISMATCH.
There is a reason these aren't well-documented; they probably
shouldn't be used in most cases. You should have seen a very
specific error message in your .log file or screen output indicating
that this situation was relevant (src/gmxlib/checkpoint.c, around
line 1606).
I also need to understand something. What exactly does the
tpbconv do when only -s and -nsteps or -extend options are
supplied - it seems that it takes all the information(mass,
topology, restraints) from the previous tpr file and just
changes the init_step parameter and the number of steps till
which the simulation should run.
All it does is modify the number of steps specified in the input
file; init_step should be untouched. The step from which the
simulation is continued is in the .cpt file.
Now if that is the case, I am still unable to understand that if
the cpt file is NOT provided to mdrun (or a mismatched one is
provided), how does mdrun obtain the coordinates, velocities,
box-dimensions of the last frame. If it doesn't use the ones of
the last frame, what does it really use?
These are two cases. If (1) an invalid .cpt file is provided, the
simulation should stop with a fatal error (in checkpoint.c,
described above); if (2) a checkpoint is not provided at all, then a
completely new simulation is started, and the "last frame" is
non-existent. The simulation begins at time zero.
If it gets them from the new_tpr file, and the new_tpr file gets
it from previous_tpr file via tpbconv, then how does that ensure
continuation from the last frame, because the previous_tpr file
might have been compiled even before the simulation started. And
as far as I know, it is purely an input file to mdrun and has no
information on the last coordinates/velocities of the mdrun.
If you provide a .tpr file to mdrun and the checkpoint file is
invalid, the simulation should have stopped, per the fatal error
given in checkpoint.c (described above). The contents of your .log
file should make clear exactly what mdrun is doing and where it's
starting.
In my case, I use tpbconv with just nsteps and old_tpr and supply the
exchanged .cpt file. Mdrun does not crash, but none of the files get
appended. All files start from the first continuation step. The logfile
has no error. Same is the case with the #rexlog0.log# file which is the
logfile which gets overwritten. I don't know what conclusion to draw -
would it make sense to compare the last frame in the .cpt file and the
first frame in the new xtc file? Should they match if the cpt file has
infact been used by mdrun?
If the frames correspond to the same point in time, the coordinates, etc should
be the same. This is certainly easy enough to test in a few seconds.
-Justin
Pooja
In the case you describe, "new.tpr" and "previous.tpr" differ only
in the number of steps, therefore the state contained therein
corresponds to the beginning of the simulation, i.e. time zero.
-Justin
You may have answered this before but I have tried and failed
in understanding. I would request you to help me in
understanding the above. I would really appreciate it.
Regards
Pooja
--
========================================
Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu <http://vt.edu/> | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
========================================
--
gmx-users mailing list gmx-users@gromacs.org
<mailto:gmx-users@gromacs.org>
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the www
interface or send it to gmx-users-requ...@gromacs.org
<mailto:gmx-users-requ...@gromacs.org>.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
--
Quaerendo Invenietis-Seek and you shall discover.
--
========================================
Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
========================================
--
gmx-users mailing list gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
