[gmx-developers] Geometry-dependent (non-spherically symmetric) potentials

[ms]

Resuming old thread because I need some advice (see below)

On 11/01/11 16:55, hess at sbc.su.se wrote:
>> On 11/01/11 16:32, hess at sbc.su.se wrote:
>>> Hi,
>>>
>>> Are these 3 particles completely independent or are two of the particles
>>> somehow bound together?
>>> In the latter case you could use and modify the generic charge group
>>> inner loops.
>>
>> Latter case. Thanks for the suggestion -can you elaborate on this, just
>> to help me understanding why and how this is a viable opportunity? :)
>> thanks!
>>
>> m.
>>
>
> Atoms in the same charge group are kept sequential in all circumstances
> in Gromacs, in particular they end up sequentially in the neighbor list.
>
> When you set the env.var. GMX_NBLISTCG interaction are calculated
> charge group wise with plain C code in src/gmxlib/nonbonded/nb_generic_cg.c.
> So you will then have access to all 3 coordinates at once.
>
> Berk
>
>>> Berk
>>>
>>>> Hi,
>>>>
>>>> While I understand that all non-bonded gmx potential shapes are
>>>> intended
>>>> to be spherically symmetric, for a project of mine it would be helpful
>>>> to be able to have a non-bonded pair potential which is
>>>> geometry-dependent (that is, depending on the angle between 3 atoms).

I probably wasn't clear before, I don't want the potential to be applied 
on only 3 atoms in my system, but on *all* atoms that belong to certain 
atomtypes (for every A-B···C triplet that meets).

So, what I would want to do is to hack with an interaction (Coulombic or 
VdW but Coulomb would be just good) so that it is dependent on the 
A-B···C angle.

Now I'm trying to look at the code and the online docs, and it's a bit 
daunting. It seems to a first look that what I want to do amounts to 
adding some clause to the nonbonded kernel so that if we're talking of 
atoms of type B and C and B is bound to an atom of type A, then I want 
to multiply for something that depends on the angle. Am I correct in the 
approach?

The first problem I see with it is that the generic C kernel is not used 
if not for debugging and that assembly kernels are used for performance 
reasons; but while I can manage to tinker with C, assembly is by far 
beyond my skills. So I wonder if I can fudge the forces *later*, after 
that the fast assembly calculation is done. If so, *where* should I do 
that? and is it viable? And since we're here, what is the order of 
magnitude of the computational overhead expected?

Thanks a lot.
Massimo

-- 
Massimo Sandal, Ph.D.
http://devicerandom.org