Re: [AMBER] annoying elapsed time in mdout of amber18

From: Song-Ho Chong <>
Date: Fri, 28 Sep 2018 16:15:24 +0900

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.


2018年9月28日(金) 5:36 David Case <>:

> 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 mailing list
Received on Fri Sep 28 2018 - 00:30:02 PDT
Custom Search