Re: [AMBER] Automated restart

From: Eugene Radchenko <>
Date: Sat, 8 Aug 2015 21:25:27 +0300

Hi David,

-----Original Message-----
From: David A Case
Sent: Saturday, August 8, 2015 3:42 PM
To: AMBER Mailing List
Subject: Re: [AMBER] Automated restart

> On Sat, Aug 08, 2015, Eugene Radchenko wrote:
> > I have encountered the "Calculation halted. Periodic box dimensions
> > have
> > changed too much from their initial values" error and see an advice here
> > to restart the calculation
> > from
> > the latest restart file.
> >
> > Actually I think it would be nice if pmemd.cuda could reset the grid
> > automatically when such condition occurs.

> We might consider this, but this should be a rare event; or maybe it
> becomes
> more common for certain types of simulations(?). Are you seeing this a
> lot?
> Is there something unusual about the types of systems you are simulating?
> Does this happen at the very beginning of your equilibration, or at later
> times?

I don't have much of statistics yet, but the event seems somewhat random,
i.e. no obvious risk factors. For example, I have two very similar systems
prepared by CHARMM-GUI (and using their simulation protocol and parameters).
One of them runs nicely in full pmemd.cuda mode (even minimization) but for
another minimization only works in CPU mode but equilibration gives this
error anyway soon after it gets to the NPT simulation. Evidently the first
system just does not hits the box change limit.

> > But failing that, is there a nice way to automate the restart? In other
> > words, how to determine the right number of steps for the restarted
> > simulation?
> I'm not sure I understand your request. There is no (obvious) "right
> number"
> of steps when you continue, as far as I can see.

I mean, is there a way for AMBER to find out how many steps were already
done before the restart (and so how many steps are remaining until
completion of the planned run)? If I just change the input restart file it
will try to repeat full number of steps specified in the mdin file?
Of course it can be done by careful manual analysis of mdout/trajectory
files and regeneration of mdin file, but I feel there should be a better way

> ....dac

Thank you for your help

AMBER mailing list
Received on Sat Aug 08 2015 - 11:30:02 PDT
Custom Search