[gmx-developers] Adding computing kernels in shared linked library

[Mark Abraham]

On 25/08/2011 10:40 PM, Sebastian Jodłowski wrote:
> On 25 August 2011 12:09, Mark Abraham<Mark.Abraham at anu.edu.au>  wrote:
>> On 25/08/2011 7:11 PM, Sebastian Jodłowski wrote:
>>> But how could it be a non-reproducible calculation if every run of
>>> non-library version gives literally the same results and every run of
>>> library version gives also the same results (but different from from
>>> non-library version) - it is a deterministic algorithm and all
>>> calculations are done in the same order.
>> Each calculation on its own can be reproducible, but they do not necessarily
>> reproduce each other. For example different compilation and/or linking
>> optimization might lead to different orders of operations and thus results.
>> See http://www.gromacs.org/Documentation/Terminology/Reproducibility
>>
>>>   Adding -reprod doesn't change
>>> anything.
>> OK. Can you compile both versions without optimizations, and link
>> statically, and see if they can reproduce each other? If not, then you will
>> have to get out a debugger and find the point they diverge.
>>
>> Mark
>>
> I run configure script with --disable-cpu-optimization
> --disable-x86-64-sse, compiled and linked statically. Nothing changed
> - results differ.

That doesn't set compilers to not optimize, i.e. you want CFLAGS=-O0.

> I run valgrind on mdrun and for 100 step of minimization set in
> mini.mdp file do_cg() is called 148 times in non-library version
> wherease in library version it is called only 132 times.

That won't help you find why they diverge, unfortunately. They diverge 
because some values differ at some point.

Mark
>
>>> Sebastian
>>>
>>> On 25 August 2011 01:43, Mark Abraham<Mark.Abraham at anu.edu.au>    wrote:
>>>> On 25/08/2011 12:52 AM, Sebastian Jodłowski wrote:
>>>>> I'm trying to add some features (e.g. interactions with membrane) into
>>>>> nb_generic_kernel. I've written all my stuff, tested it hardly and
>>>>> everything seems to work perfectly - all results are correct. Next
>>>>> step, which I would like to performe, is to extract my kernels and
>>>>> move them to the external library. So I added my lib(for now empty
>>>>> lib) to gromacs makefiles(all of them), and inlcuded my lib header in
>>>>> the nb_generic.c. In that place gromacs compiled and linked properly.
>>>>> I cut my kernel code from the nb_generic_kernel() body and above it I
>>>>> created function my_kernel() which consist body of my kernel. All
>>>>> parametres are passed via pointers and kernel is called in its earlier
>>>>> body's place in nb_generic_kernel(). Then I tested it again -
>>>>> everything works great. So I finally moved my_kernel into the library.
>>>>> Gromacs compiled and linked properly so I started testing. The results
>>>>> are already wrong at the stage of minimization. I performed 100 steps
>>>>> of minimization and version without external library calls 78144 times
>>>>> my_kernel wherease with external library my_kernel is called 69696.
>>>>> (What the hell?)The results start to differ at about 60% (45000th
>>>>> calls of my_kernel).
>>>> Sounds like you're managing to do a non-reproducible calculation
>>>> non-reproducibly. Perhaps mdrun -reprod will help.
>>>>
>>>> Mark
>>>>
>>>>>   I have no idead what's going on and I spent
>>>>> several days looking for the bug and couldn't find it. I would like to
>>>>> notice that i don't know how gromacs minimization works and have no to
>>>>> time for studing these code(but I pretty good analised how computing
>>>>> of forces works).
>>>>> Has anybody ever met something similar? Or has any experience with
>>>>> writing libraries for gromacs?
>>>>> Greetings
>>>>> Sebastian Jodlowski
>>>> --
>>>> gmx-developers mailing list
>>>> gmx-developers at gromacs.org
>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>> Please don't post (un)subscribe requests to the list. Use the www
>>>> interface
>>>> or send it to gmx-developers-request at gromacs.org.
>>>>
>> --
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the www interface
>> or send it to gmx-developers-request at gromacs.org.
>>