[gmx-developers] Re: triggering GMX_NB_GENERIC produces wrong interactions

[Igor Leontyev]

Indeed, setting GMX_NO_SOLV_OPT along with GMX_NB_GENERIC works fine.
Thanks Mark and Berk.

See more details bellow
_____________________________

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 :-)

The model of interest is not pairwise.

>>>
>>>> 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.
>

My test system is a box of 216 water molecules (as indicated in the original
post).

>>> 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!)
>

Being out of office I don't have access to the working PC, now log-files are
attached. The log report: "Found environment variable GMX_NB_GENERIC.
Disabling all interaction-specific nonbonded kernels", sounds like what I
need, although, without GMX_NO_SOLV_OPT it does not work.

>>> 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)

The form of interactions remains the same, but charges need to be adjusted
each step according to the acting field. In this case, the trick with
"after-process" electric field calculation, which can be done without code
modification (by using "-rerun" option), does not help. It turned out that
extracting the electric field from mdrun "on a fly" is not trivial or 
results in a significant lost in computational efficiency. In this case, an 
additional subroutine which will calculate only electric forces on 
polarizable atoms might be more beneficial to take an advantage of assembler 
optimized kernels. Then the forces can be easily converted to electric 
fields. Any ideas, would be appreciated.

>>
>> 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.

Where the construction of neighbourlists can be learned?

> 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
>

Just to make sure, suppose I have a protein (12K atoms) immersed in water
box (50K atoms). The use of  gmx_nb_generic_kernel routine instead of
nb_kernelNNN routines (without assembly loops) will result in significant
(>3 times) lost of computational efficiency. Is it correct?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: water216_nb_generic.log
Type: application/octet-stream
Size: 14917 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100512/dc45525b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: water216_NULL.log
Type: application/octet-stream
Size: 16429 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100512/dc45525b/attachment-0001.obj>