GitLab

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

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.

CustomManyParticleForce offers two different "permutation modes".  Implemented it for Reference and CPU platforms.

Updated Context::getParameter() and Context::setParameter() error messages to also print name of incorrect parameter to aid debugging.

- Don't make a Copy method on FunctionInfo
- Have the Copy() methods on the TabulatedFunction subclasses return a pointer

necessitated creating a Copy method to do that on TabulatedFunction classes.

segfaults when you use the long-range dispersion correction with the
CustomNonbondedForce if the force uses TabulatedFunction objects. Basically, it
prevents the copy from taking ownership (and deleting) the functions in its
destructor.

The use cases for CustomNonbondedForce copying currently is to recompute the
long-range prefactor if the parameters change (so the CustomNonbondedForceImpl
kernels need a copy of the Force object). Doing a full (deep) copy would be a
bit slower (although would only need to be paid once for each
CustomNonbondedForce object being used).