GitLab

- Remove API change for AmoebaAngleForce so it goes back to only taking degrees.
  Handle conversion via a pythonprepend (since stripUnits is done in C++ now).
- Do the same thing for TorsionTorsionForce, since angles are in degrees again
- Add AmoebaVdwForce and AmoebaWcaForce tests

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.

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

@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.