Sorry if I am jumping in on someone else's conversation...
I remember hearing something about "errors in the forcefield building up
over long timescales"
It was something about restarting jobs every ~100 ns to make sure that
didn't happen.
That being said, I can't seem to find that question nor the citation. I
thought it was my Mertz or Simmerling, but google isn't helping.
Am I just dreaming this or can one of the experts chime in?
Thanks,
Jonathan
On Thu, Apr 30, 2015 at 1:45 PM, Jason Swails <jason.swails.gmail.com>
wrote:
> 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
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Apr 30 2015 - 11:00:09 PDT
