GitLab

- Add an informative __repr__ to Topology
- Add __len__ to Chain and Residue to quickly tell how many residues or atoms
  are in them, respectively

This was actually fully supported already, since it parsed pairtypes and
assigned the exception parameters correctly from there. All this does is throw
an exception when pair parameters are not defined and gen-pairs=no.

Due to a bug that was uncovered in mdtraj with scipy's NetCDF implementation
regarding mmapping, scipy started issuing the following warning if any NetCDF
variable objects had references remaining after closing the file:

/.../lib/python2.7/site-packages/scipy/io/netcdf.py:287:
RuntimeWarning: Cannot close a netcdf_file opened with mmap=True, when
netcdf_variables or arrays referring to its data still exist. All data arrays
obtained from such files refer directly to data on disk, and must be copied
before the file can be cleanly closed. (See netcdf_file docstring for more
information on mmap.)

We were already copying data to avoid segfaults on some scipy versions, but
there were still references to variables that went out of scope shortly after
the NetCDF file was closed.  Simply deleting these references gets rid of the
warning.

Virtual sites are never created by the OpenMM system, and their information is
not parsed from the Gromacs topology file. For now just throw an exception
rather than let them run, since TIP4Pew behaves *very* strangely...

Gromacs uses the preprocessor to replace previously #define'd tokens in strings.
This is used, for instance, to override certain parameters without having to
introduce new file types.  This is how Gromacs implemented ff99SB-ILDN (i.e., by
simply replacing the chi torsion for isoleucine, leucine, aspartate, and
asparagine with a define token).  So OpenMM *was* missing some in-line
parameters that were defined.

The immediate consequence I see is that whenever someone tried to run
ff99SB-ILDN with OpenMM, what they were *really* getting was ff99SB. Not sure
where else, if anywhere, this kind of thing was happening.

Prints out a more helpful error message than a weird regex-based missing
"groups" attribute on NoneType.

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

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.

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.

Adds a test for it as well.

files.

Some topology files have some of the nonbonded pairs in the Lennard-Jones matrix
pointing to a 0 entry in the HBOND_ACOEF and HBOND_BCOEF arrays. This commit
simply skips over those entries, having previously checked that all entries in
the 10-12 sections are 0.  There is actually an example of this already in the
test suite (see ff14ipq.parm7), but this fortuitously did not cause any
difference in those test results.

The reason this bug is not evident in that test case is because the A- and
B-coefficients pulled when the index was -1 (later decremented to -2) was also
coincidentally 0. However, if this was not the case (as it does not *have* to
be), then who knows what could happen.

This also adds more of a check against 10-12 topology files. ParmEd actually
supports using the 10-12 potential in OpenMM when specified in the Amber prmtop,
but it is sufficiently rare that it is not worth porting to OpenMM, IMO.