[gmx-developers] Geometry-dependent (non-spherically symmetric) potentials
devicerandom at gmail.com
Mon Jan 24 00:53:44 CET 2011
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
>>> So you will then have access to all 3 coordinates at once.
>>>>>> While I understand that all non-bonded gmx potential shapes are
>>>>>> to be spherically symmetric, for a project of mine it would be
>>>>>> 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
> 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
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:
"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"
> 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 Sandal, Ph.D.
More information about the gromacs.org_gmx-developers