Hi,
I believe this was the specific driver I used:
http://www.nvidia.com/object/linux-display-amd64-313.30-driver.html
I'm running the benchmark now on the super-duper-clocked geforce that I
believe is "working". I can't do it on the other Titan as I've RMA'd it.
Dunno how long it will take as my CPU is only a quad core i7 :(
Will post my results back when done.
br,
g
On 30 May 2013 03:42, Jason Swails <jason.swails.gmail.com> wrote:
> 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
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 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 Thu May 30 2013 - 02:00:02 PDT
