GitLab

'const char*' by passing it straight to the std::string constructor rather than
through a reinterpret_cast.  This solves segfaults when trying to use the OpenMM
C-API (which is auto-generated from the generate*Wrappers.py scripts) when used
with gcc/g++.  clang and clang++ seem to accept this (perhaps why it was not
caught before).

After these changes, the OpenMM-Tinker binding works again with the current git
version of OpenMM.

Added catch for zinc.

Added catch for zinc.

Renamed methods for dealing with TabulatedFunctions to avoid problems in wrapper APIs.  Also fixed a few bugs.

Fix case when OBC2 GB model is used and the salt concentration is non-zero. When
the salt concentration is non-zero, the customgbforces implementation has to be
used (since the native kernel does not support salt concentrations).  However,
since the native kernel runs ~2x faster on CUDA (and most likely far more
efficiently on CPU and Reference, most likely), it is worth continuing to use
the native kernel when possible.

implicitSolventKappa is provided it will be used. Otherwise,
implicitSolventSaltConc will be used to compute kappa from the solvent
dielectric constant and simulation temperature.

In order to provide a target temperature, an optional 'temperature' parameter
had to be added to the function call. The docstring makes it clear that
temperature is only used for the salt concentration -> debye length conversion.

to 4 -- this would be a SyntaxError in Python3).

implicitSolventKappa the same (black-magic) way that Amber does. I have never
been able to reproduce the prefactor used to convert to kappa in Amber... sigh.

implicitSolventKappa = implicitSolventKappa.value_in_unit(1/units.nanometers)

will always fail. The only solution I've found is to take the unit of the
quantity. i.e.:

implicitSolventKappa = implicitSolventKappa.value_in_unit((1/units.nanometers).unit)

references.

convert the number to pure nanometers before using it in the GB code.