GitLab

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.

Clean up

Fix OpenCL platform on low-end devices

Close file before deleting in TestAmberPrmtopFile.py

Close PDBx file before deleting to fix windows test failure in TestPDbxFile.py

Fix test checkpoint reporter close file before repoening

Add bytes typemap

Update appveyor.yml

Fix exit status

Supress 4305 and 4244 warnings

Print the last failed tests output

Make numpy optional in test

Improve scipy skip too

Refactor TestCheckpointReporter.py to not require numpy

test on the proper file

Remove annoying -V

to precision)

numpy.

This also removes assert statements, since those can't be relied upon to *not*
be optimized away -- they should never be used to check user input sanity.

Also fixes the test case.  Everything should pass now.

Apparently CHARMM PSF files (particularly those printed by VMD's psfgen) can
have an insertion code tacked on to the end of the residue number, meaning that
casting to an integer will invariably fail.  We can't just ignore the insertion
code, though, since it will differentiate from the residues that came before and
after (which will likely have the same number -- same general idea as insertion
codes from PDB files). So instead we pull the insertion code off of the residue
number and extend the Residue object to accommodate that.

This is the port of the fix from ParmEd: ParmEd/ParmEd#98

I added a test for this case.