GitLab

underlying numpy array. This function would be used in instances where, for
instance, a certain API would send a flattened array of coordinates or
velocities with units attached, and you wanted to reshape the array into
(natom, 3) to be consistent with OpenMM's Context object.

arguments and pass them to the numpy function if applicable. That way, users get
the full flexibility of the numpy API on those particular methods AND get the
added benefit that the result has the correct units (and it all runs fast).

it.  Not only that, I got this FutureWarning:

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/simtk/unit/quantity.py:170:
FutureWarning: comparison to `None` will result in an elementwise object comparison in the future.
  if value == None:

sqrt of the variance), and average, returning a Quantity with the proper units.

This should be reasonably efficient, as it takes advantage of numpy-accelerated
methods if they're present.

parameter set.

 Changes to be committed:
	modified:   checkpointreporter.py

there is a small typo in checkpointreporter.py in openmm. line 81 has:
self._own_handle = true
instead of True.

terms of supporting PSF files that don't really conform to the "standard" way
that CHARMM prints them.

The downside is that it relies on ! comment tags which I think are comments for
CHARMM.  However, the use of !NATOM and !NBOND and other tags seem to be _much_
more conserved than the general format of the PSF file across different dialects
of PSFs.  So the current approach should be more flexible.

the same format as the rest of the CHARMM stream files I've seen.

simtk.openmm.app namespace to allow users to filter that warning out if they
want to.

single parameter.

- Convert coordinates, velocities, and box vectors into Vec3 objects to avoid a
  subtle bug in the units module with respect to silently modifying mutable
  collections in-place when converting to a new set of units.

Depressing compromise to make the ordering of atoms in improper torsions as consistent as possible with both AMBER and CHARMM

correction by default. Then add a test for using the long-range correction and
_not_ using the long-range correction.  Comment out the test using the
long-range correction since it currently segfaults.  When the fix for the
segfault is added, this test can be reinstated (but the energy has to be
updated)

This change in default makes it consistent with the default behavior for the
classical NonbondedForce, and I would have set that as the default to begin with
if I had known it was supposed to work.