[gmx-developers] triggering GMX_NB_GENERIC produces wrong interactions

Mark Abraham Mark.Abraham at anu.edu.au
Tue May 11 13:09:56 CEST 2010


On 11/05/2010 6:44 PM, Igor Leontyev wrote:
>>> Dear gmx-developers,
>>> I would like to test non-standard nonbonded interaction which can not be
>>> implemented simply defining tables.
>>
>> If the interactions are pairwise, being unable to use tables sounds
>> wildly unlikely. If you discuss your idea, you may learn about a good
>> way to do it :-)
>>
>>> According to posts on gmx-developers
>>> board, the simplest way to do this is to modify "gmx_nb_generic_kernel"
>>> subroutine. To make use the routine the environment variable
>>> GMX_NB_GENERIC should be set up. The energy comparison obtained with
>>> "set
>>> GMX_NB_GENERIC=0" and without, however, produces different energies.
>>> What can be done?
>>
>> It's probably immaterial, but setting GMX_NB_GENERIC to 1 is a better
>> idea.
>
> I didn't find any description of meaning of specific values of
> GMX_NB_GENERIC. But setting GMX_NB_GENERIC to even "3D1" produces the
> same result. BTW, may there be any relation between my issue and the
> problem reported here some time
> ago?
> http://oldwww.gromacs.org/pipermail/gmx-developers/2009-July/003505.html

Only if you have water, per Berk.

>> Look further back in the .log file to see what mdrun is reporting about
>> what nonbonded routines it is using.

And what did you find here? (Appearing to ignore people's feedback is a 
good way to make them reluctant to give it in future!)

>> Life will probably be easier if you do your development and initial
>> testing work on a single processor.
>
> Sure, but the behavior of serial versions in this particular test is
> exactly the same.
>
>>
>> You shouldn't be using PME, because it requires a particular form for
>> the nonbonded interactions... (unless that's the target of your test)
>
> Thank you for extended comments. Am I correctly understand a hierarchy of
> programming efforts? The simplest (but computationally slowest) option
> utilizes gmx_nb_generic_kernel subroutine; intermediate option is to modify
> and use nb_kernelXXX routines (without assembly loops) and the scary option
> is to modify kernel routines written on assembler? What is the approximate
> ratio between computation times of these 3 routines?

The hierarchy is roughly like that, but there are two optimization 
effects that overlap - optimizations for solvent loops (whose 
neighbourlists are constructed differently from others) and 
optimizations for chip architectures. gmx_nb_generic is the most general 
and slowest, but you may need both environment variables to trigger its 
correct use. Using either optimization singly or together will get a 
significant speedup (but only if you have water, in one case). How much 
depends on your simulation system, compilers, computer architecture, use 
of parallelism, vsites, etc. Something like 3- to 5-fold I would guess. 
You should test this yourself on a system of interest.

Mark



More information about the gromacs.org_gmx-developers mailing list