[gmx-users] mdrun with append option
Justin A. Lemkul
jalemkul at vt.edu
Thu Feb 3 01:14:23 CET 2011
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 <jalemkul at vt.edu
> <mailto:jalemkul at vt.edu>> wrote:
>
>
>
> Sai Pooja wrote:
>
> On Wed, Feb 2, 2011 at 3:15 PM, Mark Abraham
> <Mark.Abraham at anu.edu.au <mailto:Mark.Abraham at anu.edu.au>
> <mailto:Mark.Abraham at anu.edu.au
> <mailto:Mark.Abraham at 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 at gromacs.org
> <mailto:gmx-users at 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-request at gromacs.org
> <mailto:gmx-users-request at 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
========================================
More information about the gromacs.org_gmx-users
mailing list