[gmx-developers] Extracting i-j forces from nb_generic.c

[Erik Lindahl]

Hi James,

On 31 Dec 2013, at 08:15, James <jamesresearching at gmail.com> wrote:

> Dear Gromacs developers,
> 
> To measure thermal conductivity using Green-Kubo I am trying to extract the i-j atomic forces from nb_generic.c and I wonder if anyone could help me with some basic questions?
> 
> 1. If I understand correctly, ii and jj are atom numbers for atom i and atom j. These don't seem to correspond to the atoms in the order that they were read in (PDB file), however. How can I recover this order, or what is the new order?

That would be “ii” and “jnr” in the master branch. If you are only using a single thread this should correspond to the atom order in the input (although C always starts counting at 0). However, when we run in parallel the domain decomposition will mean that the particle indices change (frequently) as particules move across node boundaries. 

There are routines you can use to find the global atom indices, but you don’t want to call those from the innermost kernel. Instead I would recommend using a single thread while you develop, and later when you want to enable parallelization you can write functionality to move the properties you need (just as we move charge, etc) into the local topology when we do rebalancing between domains.

> 2. What units are the positions ix, iy, iz (again in nb_generic.c)?

nm - same as in the gro files, but it differs from PDB files that use Angstrom.
> 
> 3. nb_generic is within the loop i = i0 to i1-1 in nonbonded.c. What is this loop? Somehow related to different interaction types?

At one point we experimented with multithreading parallelism over this loop (thus the indices), but now the outermost loop is over different neighborlists. A certain particle will have different neighborlists for neighbors that only have charge, only Lennard-Jones, and both LJ+charge.

Having said that, for the future we are likely moving entirely to the new style “verlet” kernels currently used for GPUs (and that will likely be default for CPUs in Gromacs-5.0 too), but we still need to write a generic kernel there.

> 4. Later, I will also want to extract the instantaneous kinetic and potential energy of the atom in the same time-step - any advice is very welcome.

For kinetic energy you can just look at how we calculate temperature - this is easy. Potential energy is complex if you use lattice summation (PME), since you then would need to modify the grid interpolation to get potentials of individual particles.
> 
> 5. Out of interest, I notice many of the files in the release-4-6 branch are in include/ but the same files are in legacyheaders/ in the master branch. Why is this? Which should I be developing against?

We are moving pretty fast right now due to a switch from C to partial C++, which also involves a lot of cleaning-up and modularization. The master branch is the future, but legacyheaders is stuff that still hasn’t been modularized.

Cheers,

Erik