Hi,
Just to back up Dave's point, here are results showing energy for
ascii write vs netcdf write in PMEMD on 1 CPU - the difference is
zero. Another way to show that what you are seeing is unrelated to
choice of output trajectory format would be to perform a 3rd ascii run
and compare it to your previous ascii run; you should start to see
similar variations after a while.
-Dan
On Wed, Jun 1, 2011 at 7:49 AM, David A Case <case.biomaps.rutgers.edu> wrote:
> On Wed, Jun 01, 2011, Lorenzo Gontrani wrote:
>> ASCII
>>
>> NSTEP = 800000 TIME(PS) = 123410.000 TEMP(K) = 500.05 PRESS =
>> 0.0
>> Etot = 8096.9458 EKtot = 5121.5291 EPtot =
>> 2975.4167
>> BOND = 1914.0149 ANGLE = 2358.0329 DIHED =
>> 681.4969
>> 1-4 NB = 167.8290 1-4 EEL = 706.2125 VDWAALS =
>> -2310.5917
>> EELEC = -541.5777 EHBOND = 0.0000 RESTRAINT =
>> 0.0000
>> Ewald error estimate: 0.1526E-02
>>
>> BINARY
>>
>>
>> NSTEP = 800000 TIME(PS) = 123410.000 TEMP(K) = 500.07 PRESS =
>> 0.0
>> Etot = 8094.2782 EKtot = 5121.6841 EPtot =
>> 2972.5941
>> BOND = 1914.4745 ANGLE = 2356.1170 DIHED =
>> 682.1608
>> 1-4 NB = 167.6396 1-4 EEL = 707.7357 VDWAALS =
>> -2310.7221
>> EELEC = -544.8114 EHBOND = 0.0000 RESTRAINT =
>> 0.0000
>> Ewald error estimate: 0.1476E-02
>>
>
> Please see section 1.3.4 of the Amber11 manual about roundoff errors in MD.
> Since pmemd does dynamic load balancing, the division of tasks among
> processors may change from one run to the next. This affects the order of
> arithmetic manipulations, and hence to differences among trajectories that
> otherwise would be the same.
>
> You can run a test with a single thread, and should see the discrepancies go
> away.
>
> ....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
(image/jpeg attachment: E.jpg)
Received on Wed Jun 01 2011 - 07:30:03 PDT