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

[hess at sbc.su.se]

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

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.

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

Berk

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