Inquiries regarding Auto3D conformer sampling behavior for Host-Guest complexes (SDF vs SMILES inputs)

[shaldar-0999]

Hello Auto3D team,
I have been using Auto3D with the AIMNet model to sample conformers of host-guest complexes (specifically, cyclic macrocycles binding a small guest molecule). During my workflow, I have made a few observations regarding how Auto3D handles .sdf vs .smi inputs for disconnected fragments.
I want to verify if my understanding of the underlying mechanics (RDKit initialization + AIMNet geom-optimization / conf_sampling) is correct.
Case 1: Funneling of Docked SDF Inputs
Setup: I generated 5 distinct docked geometries of the guest inside a macrocyclic host and passed them as .sdf files with 3D coordinate information into Auto3D's conformer sampling.
Result: All 5 distinct starting geometries yielded the exact same set of 5 final conformers.
Question: Does Auto3D's conformer sampling completely ignore the input 3D geometries and re-embed (via RDKit) the 3D coordinates from the chemical graph even when given an SDF, or is the kinetic energy in the sampling algorithm simply enough to help all 5 starting poses escape their initial local minima and funnel into the exact same global minima for that pocket? (Note that I do get 5 distinct geometries if I perform geometry optimization instead of conformer sampling)
Case 2: Global vs. Local Search Efficiency
Setup: I tested a bare guest molecule using three methods:
Conformer sampling from an SDF (-687.6626 a.u.)
Geometry optimization from the same SDF (-687.6621 a.u.)
Conformer sampling from a SMILES string (-687.6619 a.u.)
Result: The SMILES-based conformer search yielded a higher energy than the simple local geometry optimization from the SDF.
Question: Is it correct to assume that for highly flexible molecules, a SMILES-based conformer search might miss the absolute global minimum due to sampling limits (e.g., missing specific internal hydrogen-bond networks), whereas passing an SDF gives the algorithm a "head start" inside a deeper energy well?
Case 3: "Emergent" Encapsulation from SMILES
Setup: I passed a single SMILES string containing both disconnected fragments (like [host_SMILES].[guest_SMILES]) directly into conformer sampling.
Result: I expected the guest molecule to float randomly or clash (as I did not provide any 3D geometry with properly docked guest-inside-the-host to guide the search), but Auto3D consistently output beautifully encapsulated host-guest complexes, with the host tightly wrapping the guest (Centroid-centroid (or COM-COM) distances routinely under 2/3 Å).
Question: How does Auto3D/RDKit assign the initial 3D coordinates for two disconnected fragments in a SMILES string? Does it explicitly overlap their centroids, or is this tight encapsulation purely an "emergent" thermodynamic behavior where the flexible host collapses around the guest to maximize hydrogen bonding in the gas-phase AIMNet simulation?

Thank you in advance for your time and for this excellent software! Any insights into these mechanics would be greatly appreciated.

[isayev]

Thanks for using Auto3D, and thanks for the careful write-up. You've mostly figured out the behavior correctly, and Case 3 is a good catch. Here is what happens under the hood, with the part that matters most for host-guest work.

First, the key point. Conformer sampling in Auto3D is not a kinetic or MD search. For any input it does three things. It builds the molecular graph, re-embeds fresh 3D conformers with RDKit distance geometry (EmbedMultipleConfs with a fixed randomSeed=42), and then runs a deterministic local optimization (FIRE) with the neural network potential. There is no thermal sampling, and there is no option to reuse the input coordinates.

Case 1 (SDF funneling): your first guess is right. Even with an SDF, conformer sampling drops the input 3D coordinates and re-embeds from the graph. RDKitSdfIsomer reads the SDF only for its connectivity and stereochemistry, then calls EmbedMultipleConfs. Because the seed is fixed, all 5 docked poses share one graph, so they produce the same embedded set and the same optimized conformers. The poses are not escaping their minima. They were simply never used. That is also why geometry optimization keeps them distinct: it relaxes the coordinates you give it, in place, with no re-embedding.

Case 2 (global vs local): partly right. A finite SMILES conformer search can miss a global minimum for a flexible molecule. The conformer budget is limited, RMSD pruning drops structures, and RDKit may not sample a specific internal H-bond basin. But the idea that an SDF gives conformer sampling a head start does not hold, because conformer sampling ignores the SDF geometry. The gap you saw between SDF and SMILES conformer sampling comes from the two routes building slightly different ensembles. The SDF path keeps your specified stereo and skips stereoisomer flipping. The SMILES path enumerates unspecified centers. Only your geometry-optimization run actually used the input pose. One more thing worth noting: your three values differ by about 0.3 to 0.4 kcal/mol. That is within the noise of conformer search and float32 convergence, so these are nearby basins rather than a large missed minimum. If you want a wider search, raise max_confs.

Case 3 (emergent encapsulation). One important caveat first. Auto3D was built for individual molecules, meaning single, covalently connected structures. There is no code path meant for disconnected multi-fragment inputs like [host].[guest], so this behavior is incidental rather than a supported feature. In practice, nothing special happens for disconnected fragments. There is no centroid overlap, no fragment placement, and no coordMap. A dotted SMILES parses into one molecule with two fragments, and the whole thing goes through a single EmbedMultipleConfs call. RDKit puts both fragments in one shared coordinate frame using its default inter-fragment distance bounds, so they start out compact rather than scattered. Any clashes are then relieved with MMFF or UFF. After that, gas-phase optimization does the encapsulation. With no solvent, the flexible host collapses onto the guest to maximize contacts. So the tight complex is real emergent behavior, seeded by RDKit's compact starting placement.

Two cautions for host-guest work specifically:

1. Gas-phase bias. Gas-phase optimization over-stabilizes compact, encapsulated geometries and intramolecular hydrogen bonds relative to solution. A very short COM-COM distance may be a gas-phase artifact rather than the real solution pose.
2. This is not docking, and multi-fragment input is out of scope. For [host].[guest] conformer sampling, the relative arrangement is whatever distance geometry and the collapse produce. It is deterministic but uncontrolled, and it is not something Auto3D was built or tested to do. If you have a docked pose you trust, run geometry optimization on that SDF. It preserves and refines your coordinates, unlike conformer sampling, which discards them.

[shaldar-0999]

Thank you so much for the detailed and incredibly helpful explanation!

The fact that conformer sampling completely discards the input 3D coordinates and re-embeds the graph totally makes sense! Looking into the Auto3D classes “RDKitIsomer” (for .smi input) as well as “RDKitSdfIsomer” (for .sdf input) (Auto3D/src/Auto3D/isomer_engine.py), I see that both clearly uses EmbedMultipleConformers function of RDKit – which always generates new 3D coordinates based on Distance Geometry (topology + distance bounds). So basically the moment Auto3D calls this RDKit function internally, the coordinates in the .sdf file are all ignored! That perfectly explains why my 5 distinct SDFs yielded the exact same conformer set, and why my "head start" hypothesis was incorrect.

I also greatly appreciate the warnings regarding multi-fragment inputs being out of scope for Auto3D and the inherent gas-phase bias driving the extreme encapsulation.

Moving forward, I will strictly use geometry optimization on my pre-docked .sdf files to safely preserve and refine the host-guest spatial arrangements.

Thanks again for your time and for maintaining such a great tool!