[gmx-developers] Writing the electric field (and its gradient) on particular atoms during an MD simulation
Mark.Abraham at anu.edu.au
Wed Apr 16 03:04:30 CEST 2008
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
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.
More information about the gromacs.org_gmx-developers