GitLab

* Created API for HIPPO force field

* Beginning of reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Continuing reference implementation of HIPPO

* Completed reference of HIPPO with no cutoff

* Beginning cutoffs/PME for reference implementation of HIPPO

* Continuing PME for reference implementation of HIPPO

* Continuing PME for reference implementation of HIPPO

* Continuing PME for reference implementation of HIPPO

* Completed reference implementation of HIPPO

* Cleanup and optimization to HIPPO reference

* Further cleanup to HIPPO

* Combined direct space interactions into a single loop

* Compute direct space interactions in quasi-internal frame

* Beginning of CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Continuing CUDA implementation of HIPPO

* Finished CUDA implementation of HIPPO

* More features and test cases for HippoNonbondedForce

* Serialization and Python API for HippoNonbondedForce

* Fixed sign error in computing forces

apparently SWIG typemaps maps Python's list but not set with std::set.
Instead, Python's `set` is mapped with `std::unordered_set`.

The original code of `swigInputBuilder.py` is kindly in a mess. Too much
lines in a single method `writeMethods` which causes debug becomes
difficult. Also there are a lot of warnings about
[PEP8](https://www.python.org/dev/peps/pep-0008/).

A refactoring in the future may be a good idea.

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

right).  Add a test for AmoebaMultipoleForce.

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.

Specified units for getOPTCoefficients() routine and switched µ for mu, to avoid unicode writing errors.