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

[ms]

On 23/01/11 19:39, hess at sbc.su.se wrote:

>>> 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?
>>
>
> Yes.
> And as I said before:
> When you set the environment variable GMX_NBLISTCG (during run time)
> nteraction are calculated charge group wise with plain C code in
> src/gmxlib/nonbonded/nb_generic_cg.c.

Yes but... do I want that? I mean, it's going to be horribly slow, isn't 
it? or am I missing something?
As I asked:
 >> 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?

Also in this case I don't get (yes, I'm dense!) why should I use charge 
groups... according to the online manual here:
http://www.gromacs.org/Developer_Zone/Programming_Guide/Programmer%27s_Guide

"Which atoms are home atoms to a specific node is determined by the 
master in dd_partition_system() and the actual run time atom data is 
composed in the t_mdatoms structure in atoms2md(). So if you want to add 
another force term acting on the simulation atoms you must iterate over 
the local atoms like this"

So...
 > You'll need to figure out based on atom type index there
 > which atoms you want to apply your special interaction to.

...shouldn't I just check the t_mdmatoms structure?


Sorry if I look like I'm a bit dumb but I am a bit confused!

thanks a lot,
Massimo

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