The first program generates the raw 3d coordinates from SMILES. The second minimizes the energy. At present we are feeding our 2D sdfs to the mengine and it gives problems for highly symmetrical configurations and ugly configurations, etc.

We need to modify our implementation by feeding the associated SMILES to smi2sdf (rather than SDF directly) and then apply mengine.

We will get to this work shortly as we have a series of higher priorities right now. This is just a public declaration of a known issue and intention to resolve.

“Aah, it looks like there is some van der Waal clash going on in the 2D SDF.

In general, you should not provide a 2D SDF to mengine – you should provide some form of 3D. Otherwise it’s possible that the optimization routine (BFGS IIRC) will barf on stuff such as everything being in a plane and so on.

Is there a reason that you have to feed 2D SDF’s? The role of smi23d is to get a rough set of 3D very fast (< 1 sec for this case) and mengine will work fine with that.

If nothing you could try converting your 2D SDF to a randomized 3D SDF
- but then you can’t guarantee absence of van der Waals clashes.

I’d still suggest going from SMILES via smi23d
”

“Aargh! My eyes!

No, this SDF has no chance of working with mengine – everything seems to be overlapping.

If this is what you’re doing for the other 4 structures, I can see why they might work – I assume you’re just transferring the 2D coordinates to SD format. And the 2D depictions seem to indicate that they’re relatively well laid out – so no clashes etc. Which is why the lower 4 work.”