OE Stereo

[jaclark5]

Close #1008

Problem

In the toolkit we have a permissive stereochemistry assignment stance where we assume that what a user provides should not be changed (in from_rdkit, Chem.AssignStereochemistry(rdmol, cleanIt=False)), but since OpenEye is the default toolkit it later disagrees with RDKit assignments and we currently choose to throw an error.

This is an issue if we import an RDKit molecule into OFF with from_rdkit, and then try to write to_smiles where the latter uses OpenEye (default if available).

RDKit and OpenEye Stereo Assignment

Inconsistencies between stereochemistry from RDKit and OpenEye are due to design decisions that aren't wrong, just different. This crops up especially in rings.

OpenEye is conservative in assigning stereo labels in that if it could be R or S, it chooses None instead of choosing one.

• It still holds chirality information with parity that is lost in import to the OpenFF-Toolkit.

RDKit has expanded its stereo labels

• Two labeling methods can generate different results.
  - default: legacy iterative refinement
  - new: rdCIPLabeler digraph with CIP rules (more aggressively applied than OpenEye)
• If the stereo labels could be R or S, both of the labeling methods will choose one, most of the time the same one but sometimes different.

Solution

Given that we are permissive in the stereo flags that are input with from_rdkit it makes sense to follow that through by retaining those stereo flags when writing to smiles and prevent throwing an error if OpenEye happens to be the default backend. This PR replaces that error with simply setting the stereo tag in an OEMol OESetCIPStereo instead of asking OE's opinion on the tag.

Downsides

• The resulting OE molecule after this change cannot be round tripped into OFF and retain the same stereo flags.

Related Topics

Based on this analysis I think #901 could be closed with updating documentation with disclaimers about how OpenEye has a conservative stereochemistry assignment and relies on parity or maybe a FAQ page? This issue expects that the stereo labels provided in a smiles should be retained in OpenEye. That is not a decision we have control over.

• Tag issue being addressed
• Add tests
• Update docstrings/documentation, if applicable
• Lint codebase
• Update changelog

[jaclark5]

This is actually more complex and likely not the solution. In a subset of 232 molecules from ani2x

• We start with an rdmol with stereo flags from tmos.
• import as an offmol with from_rdkit: 0 atom stereo tags are lost, 16 bond stereo flags are lost
• export to rdmol from offmol: 15 atom stereo flags are lost, 13 atom stereo flags are changed. 0 bond stereo are lost.
  - Due to AssignStereochemistry(cleanIt=True, force=True) in to_rdkit
• export to oemol from offmol: previously failed, now 199 atom tags are lost, 43 bond tags are lost.
• 588 atom tags and 40 bond tags remain through all 4 stages

[jaclark5]

I think the solution is to move to CW and CCW as discussed in #139 but I think I need to dive into the discussed material there before having a firm opinion.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.63%. Comparing base (ef074d5) to head (7b0cd88).

❗ There is a different number of reports uploaded between BASE (ef074d5) and HEAD (7b0cd88). Click for more details.

HEAD has 19 uploads less than BASE

Flag	BASE (ef074d5)	HEAD (7b0cd88)
	20	1

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.