Version 2.0.5

OEChem 2.0.5

New features

Performance improvement of importing molecules from various file formats
../../_images/ImportPerformance-Cpp.png ../../_images/ImportPerformance-Python.png
../../_images/ImportPerformance-Java.png

Note

  • OEB-OEMol - OpenEye OEBinary file format storing molecules as OEMol (multi-conformer molecule representation)

  • OEB-OEGraphMol - OpenEye OEBinary file format storing molecules as OEGraphMol (single-conformer molecule representation)

Major bug fixes

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

  • Previously, OEMolBase.NewAtom would not copy coordinates when the molecule was the OEMolBaseType.OEMiniMol implementation. This problem has been fixed.

  • 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::operator bool 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.

  • OEAddMols will no longer crash when used on OEMolBaseType.OEMiniMol molecule implementations.

  • OEBondBase.Clear will now clear generic data for OEMolBaseType.OEMiniMol molecule implementations.

  • The following changes were made to improve the support for OEFormat.CDX file format:

    • The problem that caused 2D coordinates to be flipped resulting in flipped atom stereo after round-tripping has been fixed.

    • Hydrogen counts for charged aromatic atoms such as [cH-]1cccc1 have been fixed.

    • OEBondStereo.Wavy and OEBondStereo.DoubleEither bonds are now correctly handled.

Minor bug fixes

  • The following methods of the OEAtomBase class are deprecated and will throw a warning when called:

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

  • oemolistream.GetConfTest is now const correct. The const-ness of the underlying OEConfTestBase is no longer disregarded.

  • oemolistream.GetFileName will no longer return an empty string when oemolistream constructor was called on a real file.

  • During substructure search, the warning: OESubSearch::SingleMatch() is unable to match bond stereo in the target for patterns with bond stereo, call OEPrepareSearch on the target first 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() is unable to match hybridization in the target for patterns with set hybridization, call OEPrepareSearch on the target first.

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

  • OEPerceiveChiral now sets the relevant perception flag for empty molecules.

  • OEIFlavor.SMI.Strict and OEIFlavor.SMI.Canon flavor combination is now valid for the OEFormat.SMI file format.

  • OE3DToAtomStereo and OE3DToBondStereo functions remove the stereo property of an atom (or bond), respectively, if it is not chiral or if its stereo configuration can not be determined from the 3D.

  • OEAtomBase.SetStereo and OEBondBase.SetStereo methods now remove the stereo generic data from the atoms (or bonds) when calling with the OEAtomStereo.Undefined or OEBondStereo.Undefined value, respectively.

  • OEHasAtomStereoHydrogens was fixed, it returns true for a tetrahedral atom with specified stereo and one explicit hydrogen neighbor.

  • OEHasBondStereoHydrogens was fixed, it returns true for an atom that belongs to a cis/trans double bond with one explicit hydrogen neighbor.

  • OEReadOEBFile can now be successfully used to read and round-trip an empty molecule (no atoms) to an OEB file. OEReadMolecule will still automatically skip molecules with no atoms.

  • OEBReadDataLength now takes a default parameter for the maximum length.

  • OEFormat.Default now has the same numerical value as OEFormat.SMI instead of OEFormat.ISM. As of OEChem TK 2.0.0 (the 2014.Feb release), OEFormat.SMI and OEFormat.ISM are functionally equivalent in OEChem TK’s file handling, so this is mostly a cosmetic change for consistency in that effort.

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

  • OEMaskGridByCoordsAndRadii has been corrected to fix a bug introduced in OEGrid 1.5.0 that produced grids of the wrong size.

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

Documentation changes

  • rmsd example has been added to generate RMSD alignment for multi-conformer molecules.

  • Links to the CTfile format document from Biovia (previously Accelrys, Inc.) has been updated. Note that registration is required to download this document.

  • OE2DRingDictionary.AddRings return value is now documented.

OEBio 2.0.5

New features

  • 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:

      • OEBio::OEComponentTypeBase abstract class

      • OEBio::OEProteinComponentType concrete type that identifies protein molecule of complexes.

      • OEBio::OELigandComponentType concrete type that identifies ligand molecule of complexes.

    • 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

    • The following fragment connection predicates have been added:

      • OEBio::OEHasConnectionType

      • OEBio::OEHasConnection

      • OEBio::OEHasResidueConnection

      • OEBio::OEIsChelatorInteraction

      • OEBio::OEIsHBondInteraction

      • OEBio::OEIsInterConnection

      • OEBio::OEIsIntraConnection

    • The following functions have been added:

  • The database of non-ligand residue types maintained by the OEResidueCategoryData object contained within an OESplitMolComplexOptions has been curated. Only about 40 percent of the entries previously listed under the category OEMolComplexFilterCategory.Misc remain, the remaining entries were recognized to be obscure ligands or were moved to other categories, such as OEMolComplexFilterCategory.CofactorAndLigand. The category OEMolComplexFilterCategory.DNA_RNA has been expanded to include the more obscure RNA bases.

  • Setting modelNum to 0 in the OESplitMolComplexOptions.ResetFilters method of OESplitMolComplexOptions now selects all models.

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

Minor bug fixes

Documentation changes

OESystem 2.0.5

New features

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

Minor bug fixes

  • OEAnnotation can now be successfully round-tripped through OEB.

Python-specific changes

  • HasUnsignedInt and GetUnsignedInt methods have been added to the OEInterface class Python wrapping to allow accessing command line parameters with !TYPE unsigned.

C#-specific changes

  • HasUnsignedInt and GetUnsignedInt methods have been added to the OEInterface class C# wrapping to allow accessing command line parameters with !TYPE unsigned.

OEPlatform 2.0.5

New features

  • OEGetAbsolutePath is a new function that returns the full absolute path of a file.

  • OEThread.SetStackSize has been added to allow controlling the maximum amount of stack size that the operating system thread will have when it is started with OEThread.Start.

  • If a toolkit program fails due to a license error, the paths of any license file(s) actually read will be output for diagnostic purposes.

Major bug fixes

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

Minor bug fixes

  • oepstream class has been removed since it never worked as originally intended.

  • OEUncompress and OECompress can now take size_t instead of unsigned int allowing use on data in excess of 4GB on 64-bit machines.

Documentation changes

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

C++-specific changes

  • OpenEye Toolkits header files should no longer contain the C++11 deprecated “register” keyword causing compilations with -Werror to fail.

  • oestream and derived classes will no longer allow implicit conversion to int and unsigned int. This avoids surprising behavior like the following from compiling:

    oeisstream is1;
oeisstream is2;
bool what = (is1 == is2);

OEGrid

New features

  • OEGrid TK now features more efficient use of memory while reading grids from files. Previously, several unnecessary memory allocations had sometimes been performed during the read process.

  • OEGrid TK grids are now officially capped to 4GB of memory since the API is designed around unsigned int.

Major bug fixes

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