[gmx-developers] Calling spread_vsite_f twice.

[Berk Hess]

Hi,

spread_vsite_f only modifies f and fshift.
As written in vsite.h, you can pass fshift=NULL.

We would like to add const for any pointer that is not modified,
but that often causes trouble in C. We will use this more
rigorously when we transition to C++.

Berk

On 04/13/2011 08:33 PM, Lee-Ping wrote:
> Dear all,
>
> I wish to call "spread_vsite_f" multiple times in a development version
> of GROMACS, in which I have spent the last few years implementing an
> automatic force field parameterization code.
>
> My main question is:  What variables are modified by spread_vsite_f,
> other than f itself?  If I call spread_vsite_f several times, do 'bad
> things' happen?
>
> My reasoning for wishing to do this is as follows.
>
> My subroutines compute first and second derivatives of both the energy
> and the force with respect to the force field parameters.  (This is
> computationally costly, but this is for reparameterizing a force field,
> not running dynamics.)  The first derivatives are stored in a (P*3N)
> array where P is the # of parameters and N is the # of atoms.  I plan to
> run serial jobs only, so there is no need to worry about domain
> decomposition or anything like that.
>
> I would like to parameterize a four-site water model, and this requires
> that I compute derivatives of the forces on the interaction sites which
> are "spread" over the atoms.  I intuitively expect that the force
> derivatives would be spread over the atoms in the same way as the forces
> themselves, and thus I should be able to call the spread_vsite_f
> function but substitute the "f" variable with the appropriate derivative
> "f^p".  I know that spread_vsite_f modifies fshift as well, so I will
> replace it with a dummy.
>
> However, I don't know whether spread_vsite_f changes any of the other
> variables that it is called with (i.e. gmx_vsite_t *vsite, t_idef *idef,
> etc.)  I am worried that spread_vsite_f may do some one-time work (or
> rather, once per force evaluation), and calling it multiple times in a
> single force evaluation may lead to unintended consequences.
>
> After I get this to work, eventually I would like to extend the force
> matching procedure to the virtual site parameters themselves .. that's
> in the future though. :)
>
> Your input is much appreciated.  Thank you!
>
> Lee-Ping Wang
> MIT Department of Chemistry
>