GitLab

This commit hits the CPU platform (I had previously thought it just used the
Reference generator) as well as the CustomIntegrator stream that is set
separately from the standard "integrator" stream attached to each platform for
CUDA and OpenCL platforms (it seemed to me that the Reference platform's
CustomIntegrator just used the integrator random stream).

Context into the platform rather than hacked into getRandomNumberSeed...

Someone please check this.

rather than some pre-set seed generated at construction time.

Any call to "setRandomNumberSeed" prevents this behavior (unless the generator
is seeded with 0).

Add a check and raise an exception if someone tries to use a CHAMBER-style prmtop

Implements `usesPeriodicBoundaryConditions` on `Force`s and `System`

topology file with the Amber file parsers. These do *not* currently work for
creating a system.

} else { -->
}
else {

However, these were not my additions originally, but rather part of the Amoeba
test cases that have been around for awhile. I figured while I was at it, I
might as well update these styles as well.

the barostats and andersen thermostat.

function call.

Reference platform.

the System. The System inspects all of its forces and calls
usePeriodicBoundaryConditions -- it reports 'true' if at least one of its Forces
returns 'true' for usesPeriodicBoundaryConditions.

The default Force implementation is to raise an exception (NotImplementedError).
The System implementation will return true if at least one of its Forces returns
'true' for usesPeriodicBoundaryConditions, _regardless_ of whether or not one or
more of the forces does not implement the method. If at least one of the forces
does not implement usesPeriodicBoundaryConditions and all forces return false,
an OpenMMException is thrown.

Squash the following warning:

/usr/local/openmm/include/openmm/CustomHbondForce.h:477:25: warning: field 'p3' will be initialized after field 'parameters' [-Wreorder]
        p1(p1), p2(p2), p3(p3), parameters(parameters) {
                            ^
I believe that the initializer is supposed to assign variables in the same
order they're declared in the class definition (not the same order they're
defined in the constructor argument list.

Fix typo.

Fix small bug in `simtk.unit` related to mutable sequences.

Optimization to CPU PME

Fixed uninitialized memory in variable step size integrators

found in doctests.py (and quite a bit more, too)

are NOT numpy arrays.

Disable PME stream on old versions of cufft

Modified packaging scripts so that we no longer install Python into lib