- The OEB format has been extended to support MDL enhanced stereogroup information.
- The OEB format has been enhanced to support reaction atom-atom mapping and reaction component information.
- The OEGroupBase API has been augmented to support reaction component information. In addition, new predicates have been added to loop over the new OEGroupBase collection types. See OEGroupBase.IsEmpty, OEGroupBase.GetGroupDefinition, OEHasGroupType, OEIsRxnComponentGroup, OEIsReactantGroup, OEIsProductGroup.
- The SDF reader is now more tolerant of molfile header lines that exceed the specification maximum of 80 characters. A warning is issued on read and the longer lines are truncated to 80 characters on write to prohibit generating files that do not meet the format specification.
- New functions for computing weighted RMS deviation between pairs of Cartesian coordinates, molecules, and partial molecules have been added. See OEWeightedRMSD for details.
Minor bug fixes¶
- The tag used to identify style data in OEB files has been changed. The old tag was not updated when the data structure was modified last year. As a result, OEB files with style data that were generated before 2015.Jun cannot be read with more recent toolkits. Data with the old tag will be ignored. Since style data is only used internally, we do not anticipate any read problems with OEB files generated by our customers.
- Functions OEGetFileExtension and OEIsGZip now recognize capitalized extensions (for example, .GZ).
- Several problems with the internal implementation of OEMolBaseType.OEMiniMol have been fixed.
- A problem in the SDF reader where uninitialized memory was being accessed during the perception of V3000 reaction files has been fixed.
- A problem in the SDF writer relating to relative stereochemistry has been fixed. Previously, the writer incorrectly exported an input V3000 format file as a V2000 format output, resulting in the incorrect promotion of racemic stereocollection information to absolute stereochemistry.
- A problem with the MOL2 reader that limited input lines to 80 characters has been fixed. The reader now supports 512 character lines for this format.
- New overloads of OEChem::OEWriteMolToString in C++ allow more efficient encoding of molecules to strings.
- Python functions OEChem::OEWriteMolToBytes take advantage of the new overloaded versions of the OEChem::OEWriteMolToString C++ functions to improve encoding performance.
- OEPlaceHydrogens is a new function that adds hydrogens to a molecule and builds hydrogen bonding networks, flipping amide and imidazole groups if necessary.
- The following API has been added to customize and improve the perception
of potential protein-ligand interactions:
- OEPerceiveInteractionOptions class
- OEHalogenBondInteractionHint class
- OEIsHalogenBondInteractionHint predicate
- OEIsIntermolecularHBondInteractionHint predicate
- OEIsIntramolecularHBondInteractionHint predicate
- OEHalogenBondInteractionHintType namespace (new)
- OESaltBridgeInteractionHintType namespace (extended)
- OEHBondInteractionHintType namespace (extended)
- A variant of the OESplitMolComplex function enables a more efficient two-step process. The function OEGetMolComplexFragments analyzes a molecule and returns an OEAtomBondSet vector describing the role of each fragment. Functions OECombineMolComplexFragments and OEFilterMolComplexFragments then use this information to create new subset molecules.
Minor bug fixes¶
- The function OEClearMolComplexSDData now correctly identifies data by tag prefixes.
- The function OEHasCrystalSymmetry now returns false if the molecule has a default CRYST1 record. PDB format rules lead to these default records, which should be interpreted to mean the molecule has no symmetry record.
- The description of the output parameters for the function OEExpandCrystalSymmetry has been improved.
- The Protein Preparation chapter has been expanded and an example, Preparing a Protein, has been added.
- The file type in the warning associated with the functions OESplitMolComplex and OEGetMolComplexComponents has been clarified.
- Functions OESetAllocaThreshold and OEGetAllocaThreshold have been added to manage stack memory usage. Rather than keeping track of stack usage, which impacts performance, the new functions set/get the threshold for the largest single allocation from the stack. Above the threshold, memory is allocated from the heap. Although this only indirectly controls total stack usage, it is lightweight and can help mitigate stack memory problems.