GitLab

angles are in degrees (unlike *every* other angle force out there), and
stripUnits automatically reduces all angles to radians if they come in with
units.

The approach here is to *slightly* change the API, so that
AmoebaAngleForce.addAngle interprets input angles <2*pi as radians, and >2*pi as
degrees. This is heuristic, but should work in every case out in the wild so
far.

I've also updated the documentation to reflect this behavior, and fixed the
units attached to the return value of AmoebaAngleForce.getAngleParameters() to
return degrees instead of radians.

Update the Python application layer to use both force constants when building
the AmoebaStretchBendForce.

stretch-bend test correctly.

The potential energy calculation done in the ReferenceStretchBendTest file was
updated to mirror that of the Reference kernel, but first I made sure that the
test passed *before* updating to the new energy expression, just to make sure
that the energies and forces didn't *change* with the new expression.

of just 1.  Backwards compatibility is provided by making the 2nd force constant
default to -1, which is reinterpreted as "copy the first force constant".

Updates both the reference and CUDA kernels.

typo fix

typo fix

typo fix

typo fix

@rmcgibbo and @mpharrigan convinced me I should have just fixed it myself.

Removed 'void' declarations from getCutoff/getCutoffDistance methods so that swigInputBuilder.py would correctly wrap return values.

from all .cpp and .h files.

Modified the AmoebaMultipoleForce.getSystemMultipoleMoments method with two extra arguments; toggle whether to evaluate energy/force and select maximum multipole order.

Simple fix to combining rules allowing AMOEBA VdW parameters to be zero.  Zero parameter excludes all interactions involving that particle, in agreement with TINKER.