Possible E/Z rendering issue with a macrocycle

[mjw99]

Given the following pair of SMILES:

C1CCCC/C=C\C=C\CCC/C=C/1
C1CCCC\C=C\C=C\CCC/C=C/1

Depict v1.15, CDK v2.12, (with CIP stereo Label on) renders:

The first molecule seems to have lost one of its E/Z centres during rendering. If the same is given to RDKit 2025.09.2, the following is seen:

[johnmay]

Hi Mark, so what it (non obviously) does is if it can't depict the bond in the correct config it will make it a cross bond. i.e. a cross bond here is showing this bond is in the wrong configuration. It will search through a set of valid macrocycle depictions to find the best fit but sometimes one just isn't possible.

I could do the CIP labelling before layout but that may be more confusing. It can fall back to the "bubbles" that RDKit does rather than the macrocycle zig zag but there is no mechanism there to then display the db config correctly.

[mjw99]

Ah thank you for the explanation, I was trying to figure out what exactly the "cross bond" rendering was ( I had been poking around in here )

[johnmay]

It is not ideal but allows you do stuff like this: C1CC/C=C/C1 I wonder if there is a better annotation I can add indicate.

[mjw99]

Do you by any chance have the code line reference to the point at which the "cross bond" is decided? I just want to carry out a few breakpoint analysis tests?

[sroughley]

I can think of another template for 14-membered rings which would cover @mjw99's example, but I can't figure what the final three digits on the lines in https://github.com/cdk/cdk/blob/main/tool/sdg/src/main/resources/org/openscience/cdk/layout/macro.smi#L14C1-L16 are (although they don't actually look to be used in the code?)

[mjw99]

Just exploring a bit and interestingly, if I omit the CorrectGeometricConfiguration.correct() here the first example renders without the cross-bond, but there is mismatch between the CIP label and rendering:

I'll look more in CorrectGeometricConfiguration

[mjw99]

Do you by any chance have the code line reference to the point at which the "cross bond" is decided? I just want to carry out a few breakpoint analysis tests?

Found it:

[johnmay]

@sroughley Yep you can just add it to that files and it will work. For this size ring I believe I put in most/all of the configs that don't require some extreme bending/distortion.

the first example renders without the cross-bond, but there is mismatch between the CIP label and rendering

Which is what is intended - i.e. it can't depict it so it marks it as unspecified. If you want an (E) with the cross bond it would just be in the depict code. Just move the

// Add annotations
    switch (annotate) {

Above the StructureDiagramGenerator.

[johnmay]

The best I can come up with manually is...

[sroughley]

I just came up with an additional 9 templates for 14-mr rings which take the coverage of possible E/Z non-cummulene double bond geometry combinations up from 472 (out of a possible 906) for the existing three 14-mr templates up to 808.
After some KNIME analysis, one of those patterns, whilst looking very different actually is the same as the first in the existing templates, at least in terms of the E/Z patterns it will allow:

(The top three are the existing 14-mr templates)

Off the remaining 8 templates, 7 will actually match @mjw99 's E/Z ring pattern:

I'll look into getting these new templates into a pull request tomorrow.

(The KNIME workflow could easily enough be adjusted to actually read the templates file direct from github, and also to enumerate for other ring sizes)

[johnmay]

Not sure about the last one but the others are ok :-). It's a little bit finicky to get the template generated as the scale and cansmi needs to be correct so here is the code - thanks in advance.

public static void main(String[] args) {
  String molfile = "\n" +
                   "  CDK     05122618512D\n" +
                   "\n" +
                   " 12 12  0  0  0  0  0  0  0  0999 V2000\n" +
                   "   17.4485  -16.0948    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   17.4485  -14.5948    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   14.8504  -14.5948    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   16.1494  -13.8448    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   14.8504  -16.0948    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   12.5421  -15.3448    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   16.1494  -16.8448    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   19.7567  -15.3448    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   18.8750  -16.5584    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   13.4238  -16.5584    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   18.8750  -14.1313    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   "   13.4238  -14.1313    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0\n" +
                   " 10  5  1  0  0  0  0\n" +
                   "  1  7  1  0  0  0  0\n" +
                   "  3 12  1  0  0  0  0\n" +
                   "  6 10  1  0  0  0  0\n" +
                   "  9  8  1  0  0  0  0\n" +
                   "  3  4  1  0  0  0  0\n" +
                   " 12  6  1  0  0  0  0\n" +
                   "  7  5  1  0  0  0  0\n" +
                   "  4  2  1  0  0  0  0\n" +
                   "  1  9  1  0  0  0  0\n" +
                   "  8 11  1  0  0  0  0\n" +
                   " 11  2  1  0  0  0  0\n" +
                   "M  END\n" +
                   "$$$$\n";

  double expBondLength = 1.5d;
  IChemObjectBuilder bldr = SilentChemObjectBuilder.getInstance();
  SmilesGenerator smigen = new SmilesGenerator(SmiFlavor.Unique + SmiFlavor.CxCoordinates);
  try (MDLV2000Reader mdlr = new MDLV2000Reader(new StringReader(molfile))) {
    IAtomContainer mol = mdlr.read(bldr.newAtomContainer());
    mol = AtomContainerManipulator.anonymise(mol);
    for (IAtom atom : mol.atoms())
      atom.setImplicitHydrogenCount(4 - atom.getBondCount());
    double actBondLength = GeometryUtil.getBondLengthMedian(mol);
    GeometryUtil.scaleMolecule(mol,
                               expBondLength / actBondLength);
    System.err.println(smigen.create(mol));
  } catch (IOException | CDKException e) {
    throw new RuntimeException(e);
  }
}

[johnmay]

I think originally I generated them by fusing hexagons... might be reasonable to redo this with a mix of 5/6/7/8 as well like you have.

[sroughley]

Thanks John.

I'll take a look at the code tomorrow.
That last one looks to have stretched a bit which doesn't help its cause.

I did wonder whether some of the latter templates had been generated computationally from slabs of graphite!

[mjw99]

Just serialising my learnings with the C1CCCC/C=C\\C=C\\CCC/C=C/1 example thus far.

In org.openscience.cdk.layout.CorrectGeometricConfiguration, there is conflict here in adjust(IDoubleBondStereochemistry dbs):

       if (dbs.getStereo() == getConformation2d(dbs)) { 
           return; 
       } 

dbs.getStereo() says one thing, getConformation2d(dbs) says something else. Resolution via reflection fails because the system is in a ring:

        if (ringSearch.cyclic(atomToIndex.get(left), atomToIndex.get(right))) { 
            db.setDisplay(IBond.Display.Crossed); 
            return; 
        } 

Here, the 14 atom macrocycle template has essentially molded the wrong configuration. The 2D layout of the macrocycle templates determine which E/Z bonds it can depict correctly, i.e. if the E/Z configuration should match the configuration in the template, e.g. C1CCCC\C=C\C=C\CCC/C=C/1

Interestingly, if one revisits the above RDKit example, but makes use of the external library CoorGen via:

from rdkit.Chem import rdDepictor
rdDepictor.SetPreferCoordGen(True)

the result is better and resembles some of Stephen's templates:

[johnmay]

I think cordgen uses 2d constraints/minimisation, I would like to do that too but never had time to look into it. When I generated the template I just used 6 member rings, odd size rings I drop one of the atoms. I think a better approach is to use combinations of 5/6/7 rings. There probably is some compression which could be done - or perhaps even generate them on the fly.