On Thu, 2015-04-30 at 08:04 -0400, David A Case wrote:
> On Wed, Apr 29, 2015, Andrew Schaub wrote:
>
> > I've been following this scheme for my longer production runs (
> > http://archive.ambermd.org/201103/0431.html):
> > 1) Heat system using NVT (ntb=1,ntp=0,ntt=3,gamma_ln=1.0) [20 ps]
> > 2) Equilibrate the system using NPT (ntb=2,ntp=1,ntt=3,gamma_ln=1.0) [5 ns]
> > 3) Production using NVT (ntb=1,ntp=0,ntt=1,tautp=10.0).
> >
> > So I'll start with NTT=3 for 5 ns, then switch to NTT=1 for the rest of the
> > simulation.
>
> This could get to be a *long* discussion, but since people consult the
> archives a lot, and since the title is about "microsecond simulations", a few
> notes:
>
> 1. Most biomolecular systems take more than 5 ns to converge. A small
> protein molecule will not even have had time to randomize is overall
> orientation (undergo rotational tumbling) on this time scale. Of course,
> perceptions change as computers get faster, but your schedule treats only
> 0.5% of the total microsecond run as "equilibration". This seems too small to
> me.
>
> 2. Using ntt=1 can save some time relative to ntt=3, but I'm not convinced
> that is a good tradeoff. In principle, ntt=2 should be a good compromise,
> speeding up the calculation, avoiding both energy drifts and subtle problems
> that can arise with ntt=1. Problem is that I don't have very much *personal*
> experience with ntt=2; others might want to chime in here. (I suspect that
> Amber needs a better "shake-aware" velocity randomization procedure....)
I agree with Dave here. I think ntt=3 is better, although ntt=2
generates fewer random numbers and should therefore be a little faster.
It is worth benchmarking, though, as random number generation is going
to be much cheaper than the actual force calculation, so I would be
skeptical that there is much time savings for typical system sizes.
> 3. If you use ntt=3, in most cases you should set ig=-1. If you set ig to
> some other value, be sure you understand what you are doing, and why.
Same goes for ntt=2, which also uses random numbers to assign random
velocities. (Really, for *any* stochastic method.) I'm not aware of
any proof that it causes synchronization problems (like there is for
Langevin dynamics), but using identical random streams for different
parts of your simulation can only hurt the resulting statistics.
HTH,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Apr 30 2015 - 11:00:05 PDT
