GitLab

Improve CHARMM parsing when resnums have inscodes

Fixed bug in CustomIntegrator

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.

Masses do not increase monotonically with atomic number

Also fixes the test case.  Everything should pass now.

Reduces time taken from 15.7 seconds (last commit) to 2.2 seconds by avoiding
Quantity comparisons altogether.

The old approach iterated through the entire periodic table by atomic number and
subtracted the provided mass by the element's mass and kept track of the
smallest difference. The new approach steps through the elements in order of
atomic number and bails once it hits an element with a higher mass than the
target mass (assuming masses are monotonically increasing).

On my desktop, processing 4TVP-dmj_wat-ion.psf dropped from 297 s to 15.4 s. But
15.4 s is still a bit too long...

Fix SWIG 3 support for the Python wrappers.

See swig/swig#387 for a discussion.  It would actually be nice to *not* set the
"compactdefaultargs" feature globally, since that would allow us to actually see
the real API at the Python level the same as you would see by looking at the C++
header files. But this is the only way to support both SWIG 2 and SWIG 3 easily
and avoid a lot of retooling for the SWIG input code generator.

Enabled OpenCL on OS X

Fixed a bug in OpenCL FFT

Optimization to OpenCL FFT

Fixed compilation error with latest version of SWIG

OpenCL FFT stores only non-redundant elements

Optimizations to CPU platform

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.

Implemented an optimized real-to-complex FFT

OpenCL FFT supports real-to-complex transforms

Fixed a performance regression on AMD GPUs