OEGenerate2DCoordinates has an additional 550 complex ring systems that it can use while laying out coordinates. Any structures that contain one of these complex ring systems will see dramatically better 2D coordinate generation.
OEChem::OEMCMolBaseT and OEChem::OEConfBaseT have been renamed to OEMCMolBase and OEConfBase respectively. This can only really have a technical effect on users of the direct C++ API. Python, Java, and C# users never saw a distinction between the template classes with the T suffix. For higher level language users, navigating the documentation and OEChem’s type hierarchy should be greatly simplified.
OEUncolorMol is a new function for performing tunable uncoloring strategies for an input molecule. Additional uncoloring strategies may be available in future versions.
Significant performance improvement for OEMolBase.GetAtoms. Algorithms that do molecular graph traversal should see a significant performance benefit. For example, OEShortestPath was measured to be 25% faster.
OEPreserveRotCompress added as a convenience function to ensure rotor-offset-compression is preserved when reading and writing molecules to OEB files. This function should be called on any oemolistream object that should preserve the rotor-offset-compression data needed to reproduce a smaller OEB file.
The performance of reading and writing rotor-offset-compression files has been improved, both when rotor-offset-compression data is preserved, and when it is not.
Multiple lines of a CSV file format can be read into successive conformers of a OEMCMolBase object. The SD data representing the data in the CSV file will be attached to each conformer.
OEAtomBondSet added the following new methods to support the addition and removal of atom and bond object from the set:
Adding of objects now verifies the membership of the object in the set prior to addition which will incur slightly more overhead than previous versions. This membership checking is in keeping with the spirit of uniqueness for a “set” implementation.
OEMDLPerceiveBondStereo will cause OEReadMolecule to produce fewer warning messages. OEMDLPerceiveBondStereo was creating ambiguous stereo bond marks, additional attempts are now made to apply unambiguous stereo bond marks. In some cases, this may result in >1 bond mark to a center to fulfill the requirements of the internal checking algorithm for validly marked centers. Pathological geometries remain where no valid marks can unambiguously define the stereocenter. For example, for some fused ring systems, the required (perhaps multiple) stereomarks would result in unpalatable marked stereocenters.
For some cases, OEMDLPerceiveBondStereo will not be able to apply marks that will satisfy the OEReadMolecule perception, and a warning message will be thrown by OEReadMolecule indicating that these should be redrawn or have coordinates regenerated, e.g., adding an explicit hydrogen at the bridgehead(s) to carry a stereomark.
OEMDLHasIncorrectBondStereo has been modified to check additional stereo environments for potential errors. For example, both example structures below are now identified as having incorrect bond stereo marks where previously only the left structure was identified.
OEMol can now represent conformer coordinates in OEHalfFloat (16-bit), double (64-bit), and long double (>=64-bit) precision. These molecule types can be accessed through the corresponding constants in the OEMCMolType namespace.
The following features were added to work in parallel with this new feature:
Older versions of OEChem, and thus many previously released OpenEye applications will not be able to read OEB files created from these alternative precision conformer molecules. Care should be taken to only pass these files to toolkits and applications that use at least the 2.0.2 version of OEChem. Note, this is not the default, the default is still to generate OEB files that can interoperate with older versions of OEChem.
OEMDLStereoFromBondStereo and OEMDLPerceiveBondStereo will now generate consistent atom stereo when a wedge or hash bond occurs between atoms with an angle less than 180 degrees as shown in the following figure. This will make OEChem consistent with the official Accelrys definition of stereo in this case. As well as ensuring that SMILES can be round-tripped through an OEChem generated SDF file that has had 2D coordinates automatically generated.
OEMDLHasIncorrectBondStereo had a major bug introduced in the 2014.Jun release. The bug was an incorrect array allocation and an out of bound access that resulted in nondeterministic processing of stereocenters and potential stack corruption. The 2014.Jun release should not be used for the OEMDLHasIncorrectBondStereo function.
OEWriteMolecule will no longer improperly flip bond stereochemistry of complex macro-cycles when writing to OEFormat_MDL, OEFormat_SDF, or OEFormat_CDX file formats. This was caused by the addition of automatically generating 2D coordinates when writing to these file formats in OEChem 2.0.0, the 2014.Feb release. In cases when the generated 2D coordinates are inconsistent with the cis/trans bond stereo configuration of the molecule, the coordinates will be zeroed out, i.e., the molecule will be written with no coordinates. This can occur when generating 2D coordinates for a molecule that contains a macro-cycle with specified cis/trans stereo bond configuration like the following:
Writing to the OEFormat_SDF and OEFormat_MDL file formats will no longer improperly promote structures with relative stereochemistry to absolute stereochemistry in some cases. This case was when an input structure had atom stereomarks and a molecule chiral flag of ‘0’ (i.e. relative stereochemistry) erroneously causing a promotion of relative stereochemistry to absolute stereochemistry on export to OEFormat_SDF or OEFormat_MDL. This change only affects structures that originate from the V2000 and V3000 molfile formats without 3D coordinates. Structures from SMILES and other formats don’t represent relative stereochemistry, therefore, those formats will still only translate absolute stereochemistry.
OEMolDatabase.GetTitle would sometimes return an empty title for multi-conformer OEB files that had their titles stored on the conformer. OEMolDatabase.GetTitle will now recognize this case and use the title from the first conformer if the top-level OEMCMolBase does not have a title.
Rotor-offset-compressed OEB files created on big-endian machines should now be readable on little-endian machines again. This bug was introduced in the 2011.1 release, the OEChem 1.7.5 release. The only big-endian architecture supported since then was PowerPC, and that support was dropped due to lack of usage.
OEGetDistance2 that takes a OEConfBase will now return the square of the distance instead of the distance as it should. This bug was introduced in 2014.Feb, the OEChem 2.0.0 release. OEGetDistance2 functions that take arguments other than OEConfBase, e.g, OEMolBase, never had a bug introduced and will continue to return the square of the distance between the two atoms.
OECreateInChI will no longer crash and instead throw a warning when the InChI library returns an empty string.
OEConfBase.GetTitle will be preferred over the OEMolBase.GetTitle when writing multi-conformer OEMCMolBase molecules out to file formats that support titles. Previously, users were required to set the OEMCMolBase title to an empty string, mol.SetTitle(""), to achieve this behavior. This code will continue to work, but is no longer necessary to get the more specific conformer titles to be written out. OEB files will continue to write out both titles.
The Python global interpreter lock is now handled properly by the following methods:
A race-condition was introduced in the previous release, 2014.Jun, when Python 3 support was added. This race condition would occur when using any of the above methods in a multi-threaded environment.