OK, thanks for detail explanation !
So my understanding is that there are perhaps two possible "scenarios"
maybe also implemented
as two different routines ?:
#1
CALCULATE_FORCES
#2
CALCULATE_FORCES_AND_ENERGIES
When energies are not requested in the given time step, #1 is used. If the
energies are requested in the given time step, #2 is used instead.
Regarding forces calculation/processing this slightly differ between #1
and #2 perhaps
due to some differences in order in which arithmetic/data operations
during the forces calculations are done (associativity issue - which might
be also caused by just partial control of the operations order during
parallel data processing especially on GPUs) and hence the final forces
calculated in case #1 and #2 in the same time moment might be slightly
different. This is my interpretation of all the information I got until
now to this story but the most important thing is that even if NTPR
(ene_avg_sampling) parameter may influence this way trajectory a bit, the
quality of the conformations sampling as well as values of averaged
quantities during the simulation will be perhaps almost identical.
M.
Dne Thu, 30 May 2013 04:42:10 +0200 Jason Swails <jason.swails.gmail.com>
napsal/-a:
> On Wed, May 29, 2013 at 6:00 PM, Marek Maly <marek.maly.ujep.cz> wrote:
>
>> Hi Jason,
>>
>> thanks for the explanation but to be frank I did not understand the main
>> idea.
>>
>
> I'll try to explain a little bit (but perhaps it's better to just take
> Scott's advice and trust him on that). The problem is that addition of
> floating point numbers in computers is not strictly associative. That
> is,
> a + (b + c) != (a + b) + c, due to round-off issues in the last decimal
> place or so. As a result, the numerical result of a summation on a
> computer depends on the _order_ in which those numbers are added. If you
> change the 'order of operations,' then you risk changing the exact value
> of
> the result in the last stored decimal. See the wikipedia page on
> Floating
> point accuracy:
> https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
>
> Since the force calculation and energy calculation follow different code
> paths, the 'order of operations' differs between the two routines. As a
> result, the exact forces may vary a tinytinytiny bit depending on whether
> the force or energy routine was called. This difference is tiny and
> negligible, but since classical systems of <2 bodies are chaotic these
> differences eventually manifest as completely different trajectories.
>
> As Scott said, this difference is expected, unavoidable, and conveniently
> unimportant. (In fact, some may argue it's a _good thing_).
>
>
>>
>> I understand that for system evolution by Molecular Dynamics is not
>> necessary to calculate energy
>> just forces and so that energy is calculated only when explicitly
>> requested (i.e. with NTPR step period) but what I have problem to
>> understand is why the printed (in mdout file) immediate energy value
>> E(i)
>> at step "i" should be dependent on the number of my "Energy requests"
>> before the simulation reached step "i" (i.e. dependent on NTPR value)? I
>> naturally assume that my energy requests do not influence evolution of
>> my
>> molecular system by Molecular Dynamics (e.g. do not influence forces
>> ...).
>> I see NTPR parameter just as the period in which some function
>> "CALCULATE_ENERGIES" is called to calculate all the energy components of
>> the simulated system in given moment, that's all, but perhaps I am not
>> right here ?
>>
>> How exactly "ene_avg_sampling" parameter is connected with "NTPR"
>> parameter ?
>>
>
> Like the "ntpr" parameter, the ene_avg_sampling variable tells pmemd how
> frequently you _want_ it to calculate energies. If ene_avg_sampling is
> set
> to 10, then pmemd.cuda will compute energies every 10 steps so they can
> be
> averaged. If ntpr is any multiple of 10, then pmemd.cuda will still
> compute energies _only_ every 10 steps (so that it can be averaged that
> often). As a result, the code path is dictated by the fact that
> ene_avg_sampling is 10 rather than by the value of ntpr.
>
> I hope this clarified things a little bit...
>
> Jason
>
--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu May 30 2013 - 06:00:02 PDT
