[gmx-users] Checkpointing

Mark Abraham Mark.Abraham at anu.edu.au
Wed Feb 3 06:50:15 CET 2010


On 03/02/10 16:38, Jack Shultz wrote:
> So you mean something like -cpi state.cpt -cpo state.cpt ? If so, I'll
> try this approach again. I had a little trouble doing it this way
> previously. I think I had trouble with the extension scripts doing it
> this way.

I'd equilibrate, then use "mdrun -cpi state" and see from the timestamps 
where the output .cpt is, and arrange future mdrun to use that. IIRC 
GROMACS handles life to not lose data, but does so differently according 
to the presence of -append. The more things you specify on the command 
line, the lower the chance of you have of having work done for you, in 
this regard.

Mark

> On Tue, Feb 2, 2010 at 11:56 PM, Mark Abraham<Mark.Abraham at anu.edu.au>  wrote:
>> On 03/02/10 15:44, Jack Shultz wrote:
>>>
>>> I will try it without the checkpointing flags.
>>
>> That's not quite what I said. I suggested not using *different* filenames
>> for -cpo and -cpi. What you want is the output file from a former run to
>> transparently become the input file for the subsequent one, and I expect
>> GROMACS will handle this for you if you let it. Try some things and see.
>>
>> Mark
>>
>>> If that fails, maybe
>>> I'll introduce some python into this integration. Check if the
>>> checkpoint already exists.
>>>
>>> On Tue, Feb 2, 2010 at 6:18 PM, Mark Abraham<mark.abraham at anu.edu.au>
>>>   wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Jack Shultz<js at drugdiscoveryathome.com>
>>>> Date: Wednesday, February 3, 2010 2:36
>>>> Subject: [gmx-users] Checkpointing
>>>> To: Discussion list for GROMACS users<gmx-users at gromacs.org>, Andrey
>>>> Voronkov<av at drugdiscoveryathome.com>
>>>>
>>>>> We have mdrun integrated into our distributed computing project. When
>>>>> your users suspend or close the manger it checkpoints, so when they
>>>>> open again it continues mdrun where it left off. However, when users
>>>>> reboot, it starts from the beginning. We are using this command line
>>>>> to execute the work.
>>>>>
>>>>> mdrun.exe (-v -x -c -o md.pdb -e -cpo md.next -cpi md.cpt -
>>>>> deffnm md)
>>>>
>>>> If you're using this input line always, then you're getting what you're
>>>> asking for - an mdrun that begins from the state in md.cpt. Since you're
>>>> never updating that, it doesn't change.
>>>>
>>>> Try not stipulating different -cpo and -cpi and see what the native
>>>> coping mechanism is. Otherwise, you'll have to write a bunch of scripting
>>>> logic to decide which .cpt to use each restart.
>>>>
>>>> Mark
>>>>
>>>>> I have a seperate checkpoint for output so after this simulation we
>>>>> can extend the workunit. Should we try using this append option?
>>>>>
>>>>> Checkpoints containing the complete state of the system are
>>>>> written at
>>>>> regular intervals (option -cpt) to the file -cpo, unless option -cpt
>>>>> is set to -1. A simulation can be continued by reading the full state
>>>>> from file with option -cpi. This option is intelligent in the
>>>>> way that
>>>>> if no checkpoint file is found, Gromacs just assumes a normal
>>>>> run and
>>>>> starts from the first step of the tpr file.
>>>>>
>>>>> With checkpointing you can also use the option -append to just
>>>>> continue writing to the previous output files. This is not
>>>>> enabled by
>>>>> default since it is potentially dangerous if you move files, but if
>>>>> you just leave all your files in place and restart mdrun with exactly
>>>>> the same command (with options -cpi and -append) the result will be
>>>>> the same as from a single run. The contents will be binary identical
>>>>> (unless you use dynamic load balancing), but for technical reasons
>>>>> there might be some extra energy frames when using checkpointing
>>>>> (necessary for restarts without appending).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jack
>>>>>
>>>>> http://drugdiscoveryathome.com
>>>>> http://hydrogenathome.org
>>>>> --
>>>>> 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/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/mailing_lists/users.php
>>>>
>>>> --
>>>> 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/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/mailing_lists/users.php
>>>>
>>>
>>>
>>>
>> --
>> 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/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/mailing_lists/users.php
>>
>
>
>



More information about the gromacs.org_gmx-users mailing list