Version 2.0.2¶
OEChem 2.0.2¶
New features¶
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
andOEChem::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 theT
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.
OESubsetMol
has new overloads to support use of subsetting activities using the OEAtomBondSet object to define the subset.OEMDLPerceiveBondStereo
will causeOEReadMolecule
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.Hint
For some cases,
OEMDLPerceiveBondStereo
will not be able to apply marks that will satisfy theOEReadMolecule
perception, and a warning message will be thrown byOEReadMolecule
indicating that these should be redrawn or have coordinates regenerated, e.g., adding an explicit hydrogen at the bridgehead(s) to carry a stereomark.Note
OEWriteMolecule
automatically callsOEMDLPerceiveBondStereo
when writing to theOEFormat_MDL
andOEFormat_SDF
file formats.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), andlong double
(>=64-bit) precision. These molecule types can be accessed through the corresponding constants in theOEMCMolType
namespace.The following features were added to work in parallel with this new feature:
Reading and writing OEHalfFloat (16-bit) precision conformers to the
OEFormat_OEB
file format, including rotor-offset-compressed files.Reading and writing
double
(64-bit) precision conformers to theOEFormat_OEB
file format, including rotor-offset-compressed files.Reading and writing
double
(64-bit) precision conformers to theOEFormat_XYZ
file format. By default, the XYZ writer will introspect the molecule type to determine how many significant digits to write.OEOFlavor_XYZ_SinglePrecision
andOEOFlavor_XYZ_DoublePrecision
can be used to force either 5 or 18 significant digits.OEMolBase.SetCoords
,OEMolBase.GetCoords
, andOEMCMolBase.NewConf
can now take coordinates in OEHalfFloat andlong double
precision.OEConfBase.GetCoordsPtr
signature has been changed for better performance. Users should still prefer using OEConstCoords and OEMutableCoords.Conformer geometry operations will now preserve the precision of the input conformer coordinates.
Note
These alternative precision conformer implementations are not used by default. They require the user to explicitly specify a constant from the
OEMCMolType
namespace to the OEMol constructor.Warning
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.
Major bug fixes¶
OEMDLStereoFromBondStereo
andOEMDLPerceiveBondStereo
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 generatedSDF
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 theOEMDLHasIncorrectBondStereo
function.OEWriteMolecule
will no longer improperly flip bond stereochemistry of complex macro-cycles when writing toOEFormat_MDL
,OEFormat_SDF
, orOEFormat_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
andOEFormat_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 toOEFormat_SDF
orOEFormat_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 theOEMolBase.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.OEConstCoords and OEMutableCoords will no longer crash when given an empty molecule.
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.
Minor bug fixes¶
OE3DToAtomStereo
, for the perception of atom stereo from 3D coordinates, depends on the following properties:OEPerceived_RingAtomsAndBonds
,OEPerceived_Aromaticity
, andOEPerceived_Chiral
. If any of these properties are un-set when callingOE3DToAtomStereo
, they will be automatically reperceived before calculating the atom stereo properties.OE3DToBondStereo
, for the perception of bond stereo from 3D coordinates, depends on the following properties:OEPerceived_RingAtomsAndBonds
,OEPerceived_Aromaticity
, andOEPerceived_Chiral
. If any of these properties are un-set when callingOE3DToBondStereo
, they will be automatically reperceived before calculating the bond stereo properties.OEOFlavor_ISM_ExtBonds
will no longer be used when generating SMILES withOEMolToSmiles
. This will causeOEMolToSmiles
to generate the same canonical isomeric SMILES as when writing into anOEFormat_ISM
file format.OEChem::OEMCMolType::Torsion
andOEChem::OEMCMolType::Rotation
constants have been removed.OEInitHandler
called on the options specified byOEBDefaultOpts
will now initialize the handler to the exact same set of handlers asOEInitDefaultHandler
. The noticeable difference between the two was thatOEInitHandler
would inadvertently turn on writing out theOEBondBase.GetIntType
field, resulting in larger file sizes.OEBondBase.GetIntType
was also turned on for theOEBRotCompressOpts
options as well.OEBondBase.GetIntType
will now only be turned on by theOEBAtomIntTypeOpts
options.OEMolBaseType_OEMiniMol
will now copy coordinates of other molecule implementations during copy construction.OEMCMolBase read through OEConfTestBase from non-SDF file formats should have a slightly smaller memory footprint. The
MDLParity
flag was always being stored in generic data, regardless of whether the molecule had the property or not.OEWriteMolecule
will no longer change the active conformer of an OEMCMolBase while writing to file formats that do not support multi-conformer molecules like SDF and MOL2.OEWriteConstMolecule
will no longer ignore the flavors specified by the oemolostream for theOEFormat_XYZ
format.Warning message about an invalid format used with
OEReadMolecule
was previously saying there was a problem withOEWriteMolecule
. This was incorrect, and the message now states “OEReadMolecule” instead.Molecules read through
OEMolDatabase.GetMolecule
will no longer have their indices written to the OEB file format. This was just causing file size bloat and possibly confusing behavior withOEHasMolDBIdx
when the molecule was written and then read again from OEB through an oemolistream.OEMolDatabase.GetTitle
fixed for PDB files that include data beyond the 72nd column.Some redundant information is removed from OEB files written from OEMCMolBase objects. This should make OEB files the exact same size when round-tripping molecules now instead of becoming slightly larger.
OEFormat_SDF
andOEFormat_MDL
file formats no longer support the long deprecated CPSS reaction fields. More deprecated atom and bond fields in the V2000 molfile format continue to be exported but will be removed entirely in future versions.OEMDLSetParity
added to allow explicitly setting the chiral flag status. This was added for symmetry withOEMDLGetParity
and to allow explicit control of the exported chiral flag state by the user.SMILES containing explicit hydrogens in stereo configurations were being non-optimally depicted. SMILES parsing will now set the reaction role (
OEAtomBase.SetRxnRole
) of stereo explicit hydrogens.OEMCMolBase.NewConf
will now return aNULL
OEConfBase pointer instead of crashing when passed aNULL
coordinates pointer.
Documentation fixes¶
OEMolBaseType
is now documented.OEOFlavor_XYZ
is now documented.All OpenEye code examples will now prefer to use
OEMolToSmiles
andOESmilesToMol
instead of theOECreate*SmiString
andOEParseSmiles
functions.
OEBio 2.0.2¶
Minor internal improvements.
OESystem 2.0.2¶
New features¶
Small performance improvements when writing generic data to OEB files.
OEGetHostEndian
andOEGetHostEndian
added to make template programming generic binary readers and writers easier.OEGeom3DAllZero
added to determine whether an array of floating point numbers is all zero.Many
OEMath::OEGeom
functions can now automatically up-cast OEHalfFloat to float during their operation making working with OEHalfFloat more seamless and requiring less temporary arrays.OEGeom3DReflect
added to reflect coordinates around any given axis.OECopyArray
should now be significantly faster forlong double
data arrays.
Documentation fixes¶
OEBitVector.ToHexString
more thoroughly explained.OEBitVector documentation table was malformed.
OEPlatform 2.0.2¶
New features¶
OEThread.Start
now returns a boolean value to indicate whether thread creation has failed.OEHalfFloat can now interconvert with
double
andlong double
more easily.
Minor bug fixes¶
OEFileRandomName
will now throw a warning that it is deprecated and will be removed in a future release. It is very dangerous and prone to race conditions.OEMutex data members are no longer exposed as
public
access on Windows.
OEGrid 1.4.7¶
Minor internal improvements.