[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