AMBER Archive (2008)

Subject: Re: AMBER: RE: About restart amber

From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Mon Nov 24 2008 - 15:22:44 CST

Hi Ross:
As the pore region of the transmembrane protein I am dealing with gets
deformed on long MD simulation under GB conditions (while the
extracellular portion behaves normally), I would like to continue with
GB by restraining the pore region (which was not comprised on last
run). In fact, I am not interested in the pore region in these
simulations. Is it correct to use as reference (-ref ...rst) the
restart file of previous run while adding now the new restraints?

>From a trial with nstlim=1 all restraints (given as GROUP for pmemd)
are read, as from the out file. Is anything subtly wrong that can't be
detected this way?

Thanks
francesco

On Sat, Nov 22, 2008 at 6:18 PM, Ross Walker <ross_at_rosswalker.co.uk> wrote:
> Hi Francesco,
>
>> When restraints are imposed, which reference file should be used in
>> running sander or pmemd again? I guess the "-ref ...rst" pertaining to
>> the crashed job. Correct? Does that involve any further complication?
>
> If you want an actual restart then you should restrain to the same restart file as the original run. Note, however, that when running NPT I think this leads to instabilities since there is some kind of adjustment of the box coordinates done that then means the restraints are too large. I have never actually nailed this problem down but essentially it means for constant pressure that you can only ever restrain to the same restart file as you are using for the input coordinates (-i). I think the problem originates in the fact that when you restart the box coordinates in your inpcrd file do not match the box coordinates in your -ref file.
>
> At least this problem existed back in Amber 7 - maybe it got fixed, I haven't tried it in a while. I avoid running constant pressure runs with restraints anyway because I figure the restraints are effectively giving you artificial behavior anyway. E.g. suppose something wants to elongate but the restraints stop it - really the box should change size to accommodate this elongation.
>
> That is probably complicating things though. For NVE and NVT you should just be able to use the same -ref as you did for the previous run.
>
>> In view of non minor work in restarting from a crashed job while
>> taking everything into account (not to mention the unluky situation
>> that the machine was just writing the rst file), is any major drawback
>> in making the various steps of MD short? If problems exist, how to
>> determine how much short?
>
> You should probably read the following 'very interesting' paper:
>
> http://pubs.acs.org/cgi-bin/abstract.cgi/jctcce/2008/4/i10/abs/ct8002173.html
>
> This looks at problems with repeating random number sequences and Langevin / Andersen dynamics, the equivalent behavior that occurs when you continually restart a simulation so effectively running very short MD runs. The key problem, with continuous short restarts, is that AMBER (and CHARMM and most other codes I think) do not strictly do proper restarts. That is they do not preserve the state of the random number stream. Hence if you just keep blindly restarting you use the exact same set of random numbers each time. For NVE this is not a problem but for Langevin dynamics it can become acute because you introduce correlation (in the reuse of the random number stream) in the 'random' forces applied and this can lead to all kinds of weird behavior. For reasonably long runs between restarts the correlation is 'weak' enough that it does not adversely affect the dynamics but for short gaps between restarts you can get strange behavior.
>
> The main point to take home here is that you should probably 'ALWAYS' be changing the random number seed (ig=) whenever you restart a simulation - in fact you should probably never run any two MD runs with the same seed (except for testing / debugging). A simple solution to this (in AMBER 10) is to set ig=-1 and then it will use the wallclock time in microseconds to seed the random number generator.
>
> We should probably be more explicit about this in the manual / tutorials etc but the reality is that we are only now beginning to realize that such effects exist.
>
> Good luck,
> Ross
>
>
> /\
> \/
> |\oss Walker
>
> | Assistant Research Professor |
> | San Diego Supercomputer Center |
> | Tel: +1 858 822 0854 | EMail:- ross_at_rosswalker.co.uk |
> | http://www.rosswalker.co.uk | PGP Key available on request |
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not be read every day, and should not be used for urgent or sensitive issues.
>
>
>
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber_at_scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo_at_scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu