An update:
Just got a mail from ebuyer who said:
Following extensive tests by our returns technicians, this item was found
to be faulty. A replacement product will be dispatched as soon as the RMA
is closed.
For more details check the My Orders section of www.ebuyer.com
Kind regards,
Ebuyer Customer Support
On 30 May 2013 09:33, ET <sketchfoot.gmail.com> wrote:
> 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 - 05:30:03 PDT
