[gmx-developers] Writing the electric field (and its gradient) on particular atoms during an MD simulation

[Mark Abraham]

John Chodera wrote:

> Mark suggests looking at the .c files in
> src/gmxlib/nonbonded/nb_kernel/, but I admit that all of these look
> like gibberish to me.  Is there some sort of guide to the construction
> of these nonbonded kernels, and what all these variable names mean?

Yes and no. The nb_kernelxxx_c.c files are auto-generated by the mk_nb*c 
group of files in the same directory, so the authoritative source is 
there. You can get comments in these output files by re-running mk_nb 
with the -comment flag (see -h flag for help). The xxx values indicate 
various options one might choose for the inner loop evaluations. There 
are comments at the head of each nb_kernelxxx_c.c file that describe 
these options. Pick one of the files that seem useful (e.g. xxx == 100 
is probably a good idea) and read over the commented version.

> David notes that the overhead of writing out 3x3 (symmetric) electric
> field gradient tensors could be large, but I should note that we only
> need the field and field gradients on a small subset of the solute
> atoms -- just a few atoms along the backbone of a solvated peptide,
> for example.  Even if we have to call some extra routines every 20 fs
> to recompute these fields and gradients, it wouldn't be too expensive.
>  Even rerunning the PME code every 20 fs wouldn't be all that bad, if
> we needed to do so -- though it would obviously be ideal to avoid
> this.

In an mdrun -rerun context, you'd just call your new nonbonded kernel on 
the atoms of relevance for the direct space sum, and probably have to 
suffer with the full reciprocal space sum to extract the bits of it you 
need - though perhaps the final interpolation can be reduced to just the 
atoms you need. That won't be a big saving.

In a full mdrun context, I'd suggest leaving the normal call to the 
nonbonded kernel, and making an extra call just afterwards from 
do_nobonded in src/gmxlib/nonbonded/nonbonded.c to your customized 
kernel. Then later after src/mdlib/force.c has called do_pme, you get 
its components and add them to the former and output. You'll need to 
make and manage a temporary data structure, of course.

Mark