The memory subsystem in the OpenEye Toolkits has been revamped
to allow more types of objects to pass safely between operating
system threads by default. The following objects are no longer
affected by OESetMemPoolMode:

The upgrade fixes crashes observed in the OEMolProp TK and OEDocking
TK in multi-threaded web servers. A more thorough
description of what can and can’t be done with threads with the
OpenEye Toolkits can be found in the recently updated
Multi-Threading chapter.

Care was taken to ensure the same or better level of performance
with the new system. However, if you experience a performance
degradation when switching to the Toolkit 2015.Oct release, please
do not hesitate to contact support@eyesopen.com.

OEMCMolBase.GetMCMolTitle will now be consistent when
reading single-conformer file formats. Previously, reading SMILES
and CDX files would set the title on the parent
OEMCMolBase, but MOL2, CSV, SDF, and single-conformer OEB
file formats would not.
All these file formats will now initialize the parent OEMCMolBase title
allowing more consistent behavior when annotating
conformer titles (warting) across all file formats. The conformers
can be warted, leaving the parent title intact as well.

OEChem::OEConfBase::operatorbool will now conform better
to the OEMolBase API by returning whether the
molecule contains atoms. The previous behavior was odd and unused,
returning the state of the coordinates in the conformer.

OEChem::OEConfBase::Clear will now be consistent with the
OEMolBase.Clear API effectively clearing away all
generic data, SD data, atoms, and bonds from the parent
OEMCMolBase.

OEPerceiveResidues will no longer crash when a
thread has a small stack size and the molecule is very large.

Previously, when the function OEParseSmiles was called with a non-empty
molecule, the hydrogen counts of the previously-existing atoms would be
erroneously modified to satisfy normal valences. Now, the existing atom
hydrogen counts are untouched.

The function OEReadMolecule will now attempt to
read malformed Rgroup atom information present in the atom block.
Although an atom symbol of R1 in the atom block may seem
reasonable, it does not strictly conform to the CTfile
specification. The OEWriteMolecule function will
never export information in this form, but an attempt will be made
to read malformed information on input.

The function OEReadMolecule will no longer emit a warning
when encountering the atom symbol * with CTfile format input, Instead, it
will be treated as a OEElemNo.Du atom. This is
in keeping with the return value from OEGetAtomicNum for *
and a desire to reduce the number of warnings from OEReadMolecule.

The function OEReadMolecule will now read Rgroup atom
label information from V3000 format input. Previously this information was ignored.

The function OEReadMolecule will now make a more concerted effort
to read malformed DOS line endings from input (text) files. This fix was added
to oeistream.

Trailing white spaces are now removed from SMILES titles.

When calling the OE3DToInternalStereo function, the bond stereo
is perceived from 3D even if the atom stereo perception fails.

Coordinates in MDL MOL files that cannot be parsed as a real
floating point number will now be 0.0 as per the MDL
specification. Previously, the string “NaN” would actually translate
to the floating point NaN binary representation.

During substructure search, the warning: OESubSearch::SingleMatch()isunabletomatchbondstereointhetargetforpatternswithbondstereo,callOEPrepareSearchonthetargetfirst was sometimes incorrectly
thrown. The underlying stereo perception has been revamped.

OESubSearch no longer throws the following message in
case when OEPrepareSearch is invoked on the target molecule.
OESubSearch::SingleMatch()isunabletomatchhybridizationinthetargetforpatternswithsethybridization,callOEPrepareSearchonthetargetfirst.

The OEUniMolecularRxn has been improved to reduce
the number of odd valence and broken aromatic ring results from transformations.

Explicit hydrogens created by parsing stereo in SMILES
strings is now capped to a maximum of eight explicit
hydrogens. Previously, a SMILES such as [C@@H1000000000]
would seem to make OEChem TK hang indefinitely as it tried to create
all those explicit hydrogens.

The function OEReadMolecule will now simply ignore the V3000
highlight collection information that was previously causing a read error.

Previously, the function OEWriteMolecule could emit lines exceeding 80 chars in
V3000 format for structures containing many stereocenters. This is in violation of the
CTfile specification and has been corrected.

An obscure issue causing a crash in OESubSearch or
OEQMolBase.BuildExpressions for imines and related
queries with cis/trans parity and explicit hydrogens has been corrected,
e.g., [H]/N=C/C.

OEBio::OEFragmentNetwork class is now exposed in order to allow the
investigation of the protein-ligand interactions perceived by OEDocking TK
and visualized by Grapheme TK.
The current API is read only - i.e., the user cannot build a fragment
network.

The fragment network (OEBio::OEFragmentNetwork) is a container
of typed molecules.
The following classes are available to classify molecules in a fragment
network:

A fragment (OEBio::OEFragment) is a set of atoms of a molecule
that is stored in the fragment network.

A fragment connection (OEBio::OEFragmentConnection) is a typed
link between two fragments of the network.
The following classes have been added to handle interactions perceived
by OEDocking TK
(see also OEAddDockingInteractions function):

OEBio::OEFragmentConnectionTypeBase abstract class

OEBio::OEFragmentContactInteraction

OEBio::OEFragmentHBondInteraction along with the related
OEBio::OEFragmentHBondType namespace

OEBio::OEFragmentChelatorInteraction along with the related
OEBio::OEFragmentChelatorType namespace

Protein Data Bank biological assembly files, with extensions like .pdb1.gz,
can now be read. These files use model numbers to refer to each part of an assembly
(model numbers are also used to distinguish NMR models). By default, each model
will be loaded as a separate molecule.
See splitmolcomplex for an example
of how to remove the ENDM flavor in order to load
all models from a Protein Data Bank file into a single molecule.

OERandom.GetSeed has been added to return
the current state of the OERandom class enabling
the restart of the random number generator with the given seed.

OEGridSizeMultiply has been added to safely multiply
grid dimensions together while ensuring that it will not cause the
value to overflow the integer type.

OEOwnedPtr is now move-constructable for any
C++11 enabled compiler. OpenEye’s first foray into supporting C++11
directly in our APIs. C++11 will eventually provide broader usage of
smart pointers across the OpenEye Toolkits API.

OEPlatform::OEMalloca will no longer cause crashes when
attempting to allocate amounts of memory near the maximum allowable
size_t. std::bad_alloc will now be thrown instead in these
situations. Since OEPlatform::OEMalloca is actually a
C-preprocessor macro, this change may result in user code throwing
additional compiler warnings when signed integer types like ‘int’
are passed to OEPlatform::OEMalloca.
We recommend that users change this code to use size_t to avoid these warnings.

OEOnce example code in the documentation will
now actually compile. Previously, the code would actually crash
prior to the OESubSearch memory pool refactoring of this release,
if any other thread besides the main thread called the function first.

OEScalarGrid and all other grid types will no
longer crash when the dimensions would cause overflow of an
unsignedint. The grid types will now throw std::bad_alloc
if attempting to make the grid memory larger than 4GB.