GitLab

* Updated to latest values for physical constants

* Updated documentation on physical constants

* Updated Python unit definitions

* Fixed constants in test case

* Added a comment

Improve the performance of sending the AmoebaVdwLambda to Cuda using pinned host memory; Updated the AmoebaVdwForceProxy to version 3, and added backward compatibility to version 2; updated TestAPIUnits.py to handle the per particle lambda flag

Now that I have my head on straight, that is.

and DrudeLangevinIntegrator.

and VariableLangevinIntegrator

right).  Add a test for AmoebaMultipoleForce.

- 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

work for the input variable type.

cubic/quartic/pentic/etc. terms are NOT working for some reason.

expansion coefficients.

docstring says it should be (kJ/nm^2) -- the swig input generator had the
inverse.

Adds a test case for the AmoebaGeneralizedKirkwoodForce API.

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.

AmoebaBondForce.

Turns out CustomManyParticleForce is broken when adding per-particle parameters
with units.