Feature request
Could rdkit / rdkit-sys expose native bindings for Bemis–Murcko scaffold generation and 3D conformer generation/optimization?
The high-level crate already covers useful parsing and normalization operations, but these common workflows currently require downstream users to maintain their own CXX bridge.
Suggested surface
Bemis–Murcko:
RDKit::MurckoDecompose(const ROMol &) from GraphMol/ChemTransforms
- A high-level helper that returns an owned molecule (or canonical isomeric SMILES)
3D conformers:
RDKit::DGeomHelpers::ETKDGv3 / configurable EmbedParameters
RDKit::DGeomHelpers::EmbedMolecule
- hydrogen addition/removal through
MolOps::addHs and MolOps::removeHs
- MMFF parameter availability and optimization
- UFF optimization as a fallback
- molblock serialization with the generated conformer
A convenient high-level API might be split into composable operations, while a small options struct could cover the most important deterministic settings (random seed, small-ring torsions, random-coordinate retry, maximum iterations, and MMFF→UFF fallback).
Example workflow
- Parse SMILES.
- Generate a Murcko scaffold and canonicalize it.
- Add hydrogens.
- Embed with ETKDGv3 and a fixed seed.
- Optimize with MMFF when parameters are available, otherwise UFF.
- Remove hydrogens and serialize to a 3D molblock.
This would keep the entire workflow in-process and native for Rust applications, without each downstream crate recreating the same C++ wrappers and link-library list.
I’m happy to help test the API on macOS arm64 and Linux x86_64.
Feature request
Could
rdkit/rdkit-sysexpose native bindings for Bemis–Murcko scaffold generation and 3D conformer generation/optimization?The high-level crate already covers useful parsing and normalization operations, but these common workflows currently require downstream users to maintain their own CXX bridge.
Suggested surface
Bemis–Murcko:
RDKit::MurckoDecompose(const ROMol &)fromGraphMol/ChemTransforms3D conformers:
RDKit::DGeomHelpers::ETKDGv3/ configurableEmbedParametersRDKit::DGeomHelpers::EmbedMoleculeMolOps::addHsandMolOps::removeHsA convenient high-level API might be split into composable operations, while a small options struct could cover the most important deterministic settings (random seed, small-ring torsions, random-coordinate retry, maximum iterations, and MMFF→UFF fallback).
Example workflow
This would keep the entire workflow in-process and native for Rust applications, without each downstream crate recreating the same C++ wrappers and link-library list.
I’m happy to help test the API on macOS arm64 and Linux x86_64.