GitLab

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.

flags. This can cause a KeyError when trying to look up the format of the
current section when it's reading the %COMMENT line (before any Format has been
assigned).

mdtraj) does *not* fully reduce the vectors.

Also adds a test for this.

Also added a test suite for them.

truncated octahedron inpcrd and prmtop file.

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

Update the Python application layer to use both force constants when building
the AmoebaStretchBendForce.

between 1 and 2 Angstroms, or they fall outside the bounds of the neck lookup
tables.

At least on my Mac, this results in a C++ exception that does not get translated
into a Python exception (i.e., it is not catchable and crashes the application)