Project

General

Profile

Task #2829

mdrun appends when checkpoint specified by -cpi is not found

Added by Joe Jordan 2 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Difficulty:
uncategorized
Close

Description

If I invoke mdrun with all paths correctly specified:

gmx mdrun -s md.part0001.tpr -cpi md.part0001.cpt -noappend

I get the expected behavior of creating a bunch of files named md.part0002*. However, if I have a typo I will get unexpected behavior:

gmx mdrun -s md.part0001.tpr -cpi md.part001.cpt -noappend

In this case, md.part0001* files will be backed up and the simulation will just start from the tpr as if the simulation has not started yet.

There is a note which seems to be about this in the mdrun help text

There are three scenarios with
-cpi:

  • no files with matching names are present: new output files are written

but this seems like unexpected behavior if I have explicitly specified -noappend. If I have no cpt file and I give the -append flag to mdrun it will throw an error, so it seems like the reverse case of saying -noappend while not giving an actual file to -cpi should also throw an error.


Related issues

Related to GROMACS - Bug #1889: mdrun -cpi file presence dilemmaRejected

History

#1 Updated by Berk Hess 2 months ago

This is a special case of our intended, but not ideal behavior. We allow mdrun -cpi to run when no checkpoint file is found for simplifying resubmit scripts.
We can consider not allowing this when -noappend is set explicitly.

#2 Updated by Mark Abraham 2 months ago

Note that this is a subcase of case 4 I listed at https://redmine.gromacs.org/issues/1889

Berk Hess wrote:

This is a special case of our intended, but not ideal behavior. We allow mdrun -cpi to run when no checkpoint file is found for simplifying resubmit scripts.

Another user problem created by that behaviour: https://redmine.gromacs.org/issues/2344#note-13

We can consider not allowing this when -noappend is set explicitly.

That would be inconsistent. If

gmx mdrun -s md.part0001.tpr -cpi md.part001.cpt

when the cpt file is missing starts from the tpr (thus we cannot append) and writes to default filenames (I forget what they are), then

gmx mdrun -s md.part0001.tpr -cpi md.part001.cpt -noappend

should have identical behaviour because all the user did was restrict GROMACS to the behaviour it would have done anyway.

That the user has adopted the .part000n naming for their .tpr is and should be irrelevant.

#3 Updated by Mark Abraham about 2 months ago

  • Target version set to 2019.1

#4 Updated by Paul Bauer about 1 month ago

  • Target version changed from 2019.1 to 2019.2

changed target to next point release

#5 Updated by Mark Abraham about 1 month ago

  • Related to Bug #1889: mdrun -cpi file presence dilemma added

#6 Updated by Mark Abraham about 1 month ago

We need to remove part of the feature space covered by -deffnm, -append, and -cpi because we have failed for years to do a good job at implementing all of it. Users love writing scripts to manage the filenames themselves, probably because people love feeling like they're in control.

Our other option is to agree to replace/update the use of pargs in mdrun so that we are aware of the sub-case when the user directly named their .cpt file, because if that file doesn't exist then mdrun knows that something is inconsistent.

#7 Updated by Eric Irrgang about 1 month ago

Mark Abraham wrote:

We need to remove part of the feature space covered by -deffnm, -append, and -cpi because we have failed for years to do a good job at implementing all of it. Users love writing scripts to manage the filenames themselves, probably because people love feeling like they're in control.

It's worth noting (and soliciting feedback) that we have been working to avoid explicit file path manipulation by users in the gmxapi Python package, but since we're not there yet, we manage the checkpoint file for the user. In 2019, the package inserts a checkpoint file specifier when launching simulations. One way to avoid this would be to discover the default checkpoint file name through the options framework.

Our other option is to agree to replace/update the use of pargs in mdrun so that we are aware of the sub-case when the user directly named their .cpt file, because if that file doesn't exist then mdrun knows that something is inconsistent.

One challenge we've faced with gmxapi is that the initial state of the simulation is not fully defined until the point at which the checkpoint file is loaded, but that there are no hooks to modify the simulation state after the checkpoint file is loaded, and no good way to provide equivalent data or known simulation state for a simulation that may or may not have a checkpoint file. It might be easier to approach this if we could initialize working files completely before starting the simulation, such as to initialize a checkpoint file at time step 0 before the simulation is run the first time.

Also available in: Atom PDF