GitLab

when the number of molecules does not agree
with the number of holders.

createSystem for both Amber and CHARMM files.

The previous version of this code would compute
the values of d0 and m0 for every iteration. This
was unnecessary as these values are fixed at the
start of the calculation by the radii of the particles
involved. This resulted in unnecessary computation
and memory access that dramatically slowed simulations
using the GBn or GBn2 solvation models.

The new version pre-computes the values based on the
radii that are present in the system. Linear interpolation
is used, which is consistent with Amber. The previous
version of OpenMM used cubic, which gives slightly
different results.

See https://simtk.org/forums/viewtopic.php?f=161&t=6512&p=16820#p16820 for more
information

Previously, parameters were defined in multiple places -- amber_file_parser.py
and charmmpsffile.py.

Swigged python docstrings now include documented return values and type
information or their arguments. They are generated in numpydoc format.
Furthermore, all of the Python app layer docstrings have been changed
to numpydoc format. The filterPythonFiles.py script which helps to
generate the Doxygen Python API docs has been updated to reflect these
changes.

Add relevant tests (that used to fail). This also fixes a subtle bug where
switching functions were not applied when NBFIXes were specified.

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.

to support triclinic cells.

Also extend unitcell.computePeriodicBoxVectors to take Quantity inputs rather
than *just* scalars assumed to be nanometers.

now that triclinics are supported this is important).