Well, the one thing I notice is that you are using langevin dynamics (ntt =
3), and therefore you are randomizing velocities according to a random
number generator, but it is of course a pseudorandom number generator, so
unless you are changing the seed every run, you are cranking through the
exact same set of "random" velocity changes on the atoms every few thousand
steps, which I would think might tend to give you some wierd results. This
is an area in which my knowledge is asymptotic with nothing, but that is the
first thing I noticed and would be worried about. I have not personally
checked to see if you can chop a run up and get the same results for
non-statistical methods, but certainly for restart runs, that is what I
would expect. The test there would be a ntt 0 run, save a restrt every 10
steps and do 10 restrts, see if you get the same thing as a 100 step run.
Then you know the basic restrt file method is okay (this is of course within
the limits of the restrt format, we don't really support the binary restrt
format particularly well, and in 10 have actually disabled output of binary
restrts, but not input, to transition to not supporting these. So there is
also the possibility that in trying to use the binary restrt, things may
have been "not quite right", as in the past this stuff has not gotten
particularly well tested (I tried once to dope out all the issues
surrounding fortran binary file compatibility and at one point was ready to
quit having anything to do with fortran forever - how rinky dink can you
get...). Okay, so anyway, the first thing I would suspect is ntt 3, with
the pseudorandom number generator giving you an extremely biased velocity
sample.
Regards - Bob
----- Original Message -----
From: "David Cerutti" <dcerutti.mccammon.ucsd.edu>
To: <amber.scripps.edu>
Sent: Thursday, April 17, 2008 5:04 PM
Subject: AMBER: Short trajectory segments / frequent restarts causes
explosion
> Hello,
>
> This is very bothersome. I now have three examples of using short
> trajectory segments (2000 to 10000 steps at 1.5fs timestep) causes the
> system to begin to fall apart and eventually blow up.
> The first came a couple of months ago, when I was trying to submit jobs
> more frequently so I could work around a novice user who was also trying
> to use the system (in the absence of a queue, I had a check before each
> submission to see whether he had started something). I switched from
> 100,000 steps per run to 2,000. Immediately, things started to go
> slightly off. With each restart, it was as if the system was being
> slightly kicked out of its normal, happy state. The increase in RMSD was
> rather exponential, and in a few nanoseconds it maxed out at around 40A,
> with the protein completely unfolded. I went back to the original 100,000
> steps per segment and restarted from the last good set of coordinates and
> everything's been fine for tens of nanoseconds since.
> The next two examples came today when I was simulating different but
> related systems. I switched from 1,000,000 steps per leg to 10,000 to try
> and make better headway through a supercomputer queue with shorter jobs.
> Both systems showed immediate and steady increases in RMSD, one of them
> much too high to be a normal continuation of the original trajectory. I
> expect that these increases would become exponential, but I'm not going to
> wait to find out. The first example was using the netcdf coordinate
> output, the second two used .crd format, but the restart file was written
> in the %12.7f%12.7f%12.7f%12.7f%12.7f%12.7f format in all cases.
> Below is the input file I was using (the parameters are the same across
> all three runs, save for the coordinate output format as I just mentioned.
> I can't see how the more frequent restarts would really drive the system
> so far out of whack, given the degree of precision in the restart file. It
> makes me wonder, though, if something is going wrong with every restart of
> my system, and if it's just healing within 100,000 or 1,000,000 steps so
> that it's not as apparent.
>
> Thanks!
>
> Dave
>
>>>>>>
> Molecular dynamics at a slightly improved rate
> &cntrl
>
> nmropt = 0,
> ntx = 5, irest = 1, ntrx = 1, ntxo = 1,
> ntpr = 100, ntwx = 1000, ntwv = 0, ntwe = 100,
> iwrap = 1, ioutfm = 1,
>
> ntf = 2, ntb = 2,
> cut = 9.0,
>
> ibelly = 0, ntr = 0,
>
> imin = 0,
> nstlim = 1000000,
> nscm = 1000,
> t = 0.0, dt = 0.0015,
>
> temp0 = 293.0, tempi = 293.0,
> ig = 982742,
> ntt = 3,
> gamma_ln = 3.0,
> vlimit = 20.0,
>
> ntp = 1, pres0 = 1.0, comp = 44.6,
> taup = 1.0,
>
> ntc = 2, tol = 0.00001, watnam = 'WAT ',
>
> &end
> <<<<<
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Fri Apr 18 2008 - 21:20:10 PDT
