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.