Dear Jason,
Thanks for your answer.
You are right. But unfortunately, I have done many MD simulations with this
prod.in file and without ioutfm=1.
On Fri, Nov 6, 2015 at 8:30 PM, Jason Swails <jason.swails.gmail.com> wrote:
> On Fri, Nov 6, 2015 at 8:59 AM, shahab shariati <shahab.shariati.gmail.com
> >
> wrote:
>
> > Dear amber users
> >
> > I was running the second prod step. Unfortunately, due to power failure,
> > sander was stopped.
> >
> > My prod.in file is as follows:
> >
> > &cntrl
> > imin=0,irest=1,ntx=5,
> > nstlim=2500000,dt=0.002,
> > cut=10.0,ntb=2,ntp=1,taup=2.0,
> > ntc=2,ntf=2,
> > ntpr=2500,ntwx=2500,
> > ntt=3,gamma_ln=2.0,
> > temp0=300.0,
> > /
> >
>
> You never set ntwr here, which means it was left at the default value.
> That default value varies based on whether you are using sander, pmemd,
> pmemd.MPI, and maybe pmemd.cuda. It is almost certainly more frequently
> than 2500 steps, so your restart file is unlikely to correspond to the
> output at time step 2445000. It could belong to any step between 2445000
> and 2447500.
>
> Furthermore, you have not set ioutfm=1, which means that your simulation is
> printing ASCII mdcrd files. These files are notoriously susceptible to
> corruption in cases like these, where the writing buffer may not have fully
> flushed.
>
> You should *always* set ioutfm=1 in the input file, since the resulting
> trajectories are smaller, faster to read, faster to write, and store
> coordinates in higher precision. They are also more fault-tolerant.
>
> I have to have a trajectory containing 5000 ps and 1000 frames.
> >
> > After power failure, the end of the prod2.out file is as follows:
> >
> > .
> > .
> > .
> > .
> >
> >
> ------------------------------------------------------------------------------
> >
> > NSTEP = 2445000 TIME(PS) = 11390.000 TEMP(K) = 299.92 PRESS =
> > -23.9
> > Etot = -92384.3446 EKtot = 23793.4048 EPtot =
> > -116177.7494
> > BOND = 987.7799 ANGLE = 2608.5156 DIHED =
> > 3411.8147
> > 1-4 NB = 1154.3951 1-4 EEL = 14108.7303 VDWAALS =
> > 13059.2879
> > EELEC = -151508.2729 EHBOND = 0.0000 RESTRAINT =
> > 0.0000
> > EKCMT = 10071.6907 VIRIAL = 10270.6229 VOLUME =
> > 385008.3181
> > Density =
> > 1.0277
> > Ewald error estimate: 0.1991E-03
> >
> >
> ------------------------------------------------------------------------------
> >
> > To continue, I made new.in file, as follows: (nstlim =
> > 2500000-2445000=55000)
> >
> > prod complex_solvated
> > &cntrl
> > imin=0,irest=1,ntx=5,
> > nstlim=55000,dt=0.002,
> > cut=10.0,ntb=2,ntp=1,taup=2.0,
> > ntc=2,ntf=2,
> > ntpr=2500,ntwx=2500,
> > ntt=3,gamma_ln=2.0,
> > temp0=300.0,
> > /
> >
> > After completing run, I concatenated 2 mdcrd files using cpptraj.
> >
> > I saw mixed.mdcrd trajectory using vmd. In vmd, there are 999 frames
> > instead of 1000.
> >
> > Why? Is my manner wrong?
> >
>
> It might be that the mdcrd file buffer was not fully flushed when the
> power died, resulting in a partially-truncated mdcrd file. cpptraj
> *should* indicate whether or not it was able to predict the number of
> frames in the trajectory file. If it wasn't this is a good indication that
> your last frame was truncated.
>
> In which case, cpptraj did the best it could, and simply omitted the final,
> corrupt/incomplete frame from the first trajectory, which results in one
> fewer than you expect. On the whole, this is not a big problem as the
> remaining 999 frames should be perfectly valid.
>
> 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 Sun Nov 08 2015 - 04:00:04 PST
