- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: shahab shariati <shahab.shariati.gmail.com>

Date: Sun, 8 Nov 2015 15:02:29 +0330

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

Date: Sun, 8 Nov 2015 15:02:29 +0330

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:

_______________________________________________

AMBER mailing list

AMBER.ambermd.org

http://lists.ambermd.org/mailman/listinfo/amber

Received on Sun Nov 08 2015 - 04:00:04 PST

Custom Search