After reading the reply from Prof. Case and checking my simulation
results again, I realized that this has nothing to do with the amber
versions, but probably with the fact that, in my previous simulations
I have been using "formatted" restart/coordinates files, whereas in
my newer simulations, I'm using binary ones.
(I still sometimes use formatted output files since some of in-house
codes directly handles restart/coordinate files and they are not updated
to cope with the binary formats.)
Anyway, it would be much nicer if round-off errors do not affect
the elapsed time.
Song-Ho
2018年9月28日(金) 5:36 David Case <david.case.rutgers.edu>:
> On Thu, Sep 27, 2018, Song-Ho Chong wrote:
>
> > But, for some reason, right after 336 ns production run, I see
> >
> > NSTEP = 500000 TIME(PS) = 336219.999 TEMP(K) = 309.97 PRESS =
> 0.0
> >
> > instead of TIME(PS) = 336220.000 that I expected.
>
> The printed time is obtained by repeatedly adding dt to starting time, and
> what you observe is an expected feature of floating point roundoff. It's
> not
> clear why you didn't see this in earlier versions of Amber. Scripts that
> process such files will need to be made aware of what the output might look
> like.
>
> It's possible that doing something like multiplying the step number by dt,
> then adding it to the starting time, would yield more pleasing-looking
> results. Suggested code revisions are welcome.
>
> .....dac
>
>
> _______________________________________________
> 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 Fri Sep 28 2018 - 00:30:02 PDT
