Hi Jason,
Thanks for your advice. I tried as you suggested (ntpr to 1) and the
averages did match. I guess the easiest way to get the overall dv/dl
averages from multiple segments would be to just average the dv/dl values in
AVERAGES. Thanks again for your help. :)
Kind regards,
GT
On 28 April 2010 16:31, Jason Swails <jason.swails.gmail.com> wrote:
> Hello,
>
> On Wed, Apr 28, 2010 at 11:04 AM, g t <sketchfoot.googlemail.com> wrote:
>
> > Hello all,
> >
> > I was hoping someone could help me with analyzing the setup in my
> > ti_calculations. I am limited by my cluster to running jobs of 48 hours
> > only. Therefore, I am using a script that splits a large job of
> nanoseconds
> > into multiple segments of around 40 picoseconds. The script waits for a
> > unique restart file to be written and submits the next segment. As a
> > result,
> > I get multiple .out and .crd files:
> >
> > e.g.
> >
> > hexanol_complex_prod_v0_l7_no1.out (50-90 picoseconds)
> > NSTEP = 20000
> > hexanol_complex_prod_v0_l7_no2.out (90-130 picoseconds)
> > NSTEP = 20000
> > hexanol_complex_prod_v0_l7_no3.out (130-170 picoseconds)
> > NSTEP = 20000
> > hexanol_complex_prod_v0_l7_no4.out (170-210 picoseconds)
> > NSTEP = 20000
> > hexanol_complex_prod_v0_l7_no5.out (210-250 picoseconds)
> > NSTEP = 20000
> >
> > Rejoining the .crd files with ptraj is not a problem. However getting the
> > data from the out file has been troublesome. The problem is that upon
> > restarting, all the recorded numbers in the outfile are averaged for the
> > number of steps of that segment only. i.e. I don't get an average that
> > includes all the steps that preceded it
> >
> > e.g. for hexanol_complex_prod_v0_l7_no2.out:
> >
> >
> >
> > A V E R A G E S O V E R 20000 S T E P S
> >
> >
> > NSTEP = 20000 TIME(PS) = 130.000 TEMP(K) = 299.91 PRESS =
> > 5.5
> > Etot = -65097.5659 EKtot = 15993.4386 EPtot =
> > -81091.0045
> > BOND = 480.0218 ANGLE = 1275.2825 DIHED =
> > 1629.2670
> > 1-4 NB = 565.9616 1-4 EEL = 7122.1569 VDWAALS =
> > 9865.2479
> > EELEC = -102028.9421 EHBOND = 0.0000 RESTRAINT =
> > 0.0000
> > DV/DL = -0.2145
> > EKCMT = 7087.7220 VIRIAL = 7056.5130 VOLUME =
> > 261867.6828
> > Density =
> > 1.0197
> > Ewald error estimate: 0.7137E-04
> >
> >
> > These numbers don't take into account the preceding 50 picoseconds. Only
> > the
> > time seems to have continued on from the previous segment.
> >
> > I have set ntpr to write every 1000 steps and have wriitten a script to
> > average the dv/dl values that i am interested in. However in a test
> > situation the averages calculated with the script do not match that in
> the
> > 'A V E R A G E S O V E R 20000 S T E P S' section. Would it be
> accurate
> >
>
> I'm pretty sure these do not match because the AVERAGE values printed in
> the
> mdout file is averaged over every frame in the simulation opposed to over
> every ntpr frames which is all your script can do. This can be easily
> verified by changing ntpr to 1 for ~10 frames and comparing your script and
> the output file, then changing ntpr to 2 and checking that they differ.
>
>
> > to just average all the dv/dl values in the 'A V E R A G E S O V E R
> >
>
> This will give you the proper average, but only as long as each segment
> that
> you're adding has the same number of steps. The problem with doing this
> for
> files with differing numbers of steps is that a file with more frames will
> contribute more to the average, clearly. You can verify this pretty easily
> by writing on the equation for the average in each file (Ave =
> sum(data)/number points), and then extending it to each file. The total
> number of points will simply end up being, in your case, 20 000 * number
> files, so the final average is the sum of all the averages
> (sum(data)/20,000) divided by the number of files: namely the average of
> the
> averages (again, this only works because 20 000 is common to each
> simulation).
>
> 20000 S T E P S' section? It is impossible to check manually because of the
> >
> random seed issue.
> >
>
> Not quite sure what you mean here... I'd say it's impossible to check
> because not every frame used to compute the averages is printed to the
> output file... In any case, it doesn't have any bearing on what I stated
> above.
>
>
> >
> > Any advice on recalculation of segmented outfiles would be greatly
> > apprecaited.
> >
> > Kind regards,
> > GT
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
>
> Good luck!
> Jason
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
> _______________________________________________
> 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 Wed Apr 28 2010 - 09:30:05 PDT
