[gmx-users] mdrun with append option

[Sai Pooja]

On Wed, Feb 2, 2011 at 6:49 PM, Sai Pooja <saipooja at gmail.com> 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> 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>> 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.
>>
>
They do infact match! So mdrun starts from the checkpoint file provided!
Files do not get appended but runs are in continuation.

Thanks!
Pooja

>
>
> 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?
>
> 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 | (540) 231-9080
>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
>>
>> ========================================
>> --
>>  gmx-users mailing list    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.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>
>
>
> --
> Quaerendo Invenietis-Seek and you shall discover.
>



-- 
Quaerendo Invenietis-Seek and you shall discover.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20110202/ad84be0a/attachment.html>