Potential Discrepancy in Evaluated Energies Between openff-interchange 0.3.18 and 0.4.2

[asood-alg]

Description

I was trying to calculate the potential energy of a ligand using openff-interchange and openmm. I expected the potential energy calculation to be consistent across different versions of openff-interchange when using the same ligand and force field. However, I observed a significant difference in the calculated potential energy between openff-interchange version 0.3.18 and 0.4.2.

Reproduction

I am using the following test script, that is executed in two separate conda environments (see: #Software versions) with different versions of openff-interchange.

import rdkit
from rdkit import Chem
import parmed
import openmm
import openff
from openff.interchange import Interchange
from openff.toolkit import ForceField, Molecule
from openff.units import unit
import os

print(f"rdkit version {rdkit.__version__}")
print(f"openmm version {openmm.__version__}")
print(f"parmed version {parmed.__version__}")
print(f"openff-interchange version {openff.interchange.__version__}")
print(f"openff-toolkit version {openff.toolkit.__version__}")
print(f"openff-units version {openff.units.__version__}")

conda_env_name = os.path.basename(os.environ["CONDA_PREFIX"])
print(f"Conda env name {conda_env_name}")

def load_ligand_from_rdkit_mol(
    rdmol: rdkit.Chem.rdchem.Mol | None,
    residue_name: str | None = None,
    forcefield: str | None = "parsley",
) -> parmed.amber.AmberParm:
    """Load a ligand from an RDKit Mol object.

    Args:
        rdmol: An RDKit Mol object for the ligand
        residue_name: The (optional) residue name to assign to the ligand.

    Returns:
        The loaded ligand
    """
    mol = Molecule.from_rdkit(rdmol, allow_undefined_stereo=True)
    if forcefield == "sage":
        ff = ForceField("openff-2.2.0.offxml")
    elif forcefield == "parsley":
        ff = ForceField("openff-1.3.1.offxml")
    else:
        raise RuntimeError("Force-field is not available.")
    interchange = Interchange.from_smirnoff(topology=[mol], force_field=ff, box=None)
    system = interchange.to_openmm_system(add_constrained_forces=True)
    structure = parmed.openmm.load_topology(
        mol.to_topology().to_openmm(), system, interchange.positions.m_as(unit.angstrom)
    )
    ligand = parmed.amber.AmberParm.from_structure(structure)

    for residue in ligand.residues:
        residue.name = residue_name

    ligand.parm_data["RESIDUE_LABEL"] = [residue_name]

    return ligand

ligands_file = "./ligands.sdf"
supplier = Chem.SDMolSupplier(ligands_file, removeHs=False)

mol = supplier[0]

ligand = load_ligand_from_rdkit_mol(
    rdmol=mol, residue_name="L1", forcefield="parsley"
)


create_system_args = {
    "nonbondedMethod": openmm.app.NoCutoff,
    "constraints": openmm.app.HBonds,
}

system = ligand.createSystem(**create_system_args)

with open(f"{conda_env_name}-system.xml", 'w') as f:
    f.write(openmm.XmlSerializer.serialize(system))

platform = openmm.Platform.getPlatformByName('Reference')
integrator = openmm.VerletIntegrator(0.01)
context = openmm.openmm.Context(system, integrator, platform)

context.setPositions(ligand.positions)

print(f"Potential Energy {context.getState(getEnergy=True).getPotentialEnergy()}")

Given below is an example ligands.sdf file

1H1Q
                    3D
 Schrodinger Suite 2022-2.
 45 48  0  0  1  0            999 V2000
    7.8210   43.7020   49.3990 C   0  0  0  0  0  0
   10.7390   46.1550   51.6470 C   0  0  0  0  0  0
    5.1160   45.2740   51.6170 C   0  0  0  0  0  0
    4.1070   45.7240   52.7030 C   0  0  0  0  0  0
    2.7660   45.9860   51.9860 C   0  0  0  0  0  0
    1.5620   46.0860   52.9390 C   0  0  0  0  0  0
    1.4480   44.9690   53.9870 C   0  0  0  0  0  0
    2.7870   44.7400   54.7250 C   0  0  0  0  0  0
    4.0090   44.6090   53.7920 C   0  0  0  0  0  0
    4.6670   40.9170   47.4030 C   0  0  0  0  0  0
    4.0590   40.6480   48.6330 C   0  0  0  0  0  0
    4.6450   41.0930   49.8150 C   0  0  0  0  0  0
    5.8520   41.7890   49.8080 C   0  0  0  0  0  0
    6.8700   44.4890   50.1810 N   0  0  0  0  0  0
    7.2370   45.3850   51.0370 C   0  0  0  0  0  0
    6.3200   46.0740   51.7360 O   0  0  0  0  0  0
    8.6590   45.6250   51.1990 C   0  0  0  0  0  0
    9.5490   46.4520   51.9630 N   0  0  0  0  0  0
   10.7730   45.2130   50.7360 N   0  0  0  0  0  0
    9.5340   44.9120   50.4780 C   0  0  0  0  0  0
    9.0610   43.9200   49.5710 N   0  0  0  0  0  0
    7.6000   42.7620   48.5320 N   0  0  0  0  0  0
    6.4450   42.0610   48.5810 C   0  0  0  0  0  0
    5.8550   41.6320   47.3960 C   0  0  0  0  0  0
    4.6775   45.4225   50.6302 H   0  0  0  0  0  0
    5.3628   44.2225   51.7641 H   0  0  0  0  0  0
    4.4581   46.6481   53.1622 H   0  0  0  0  0  0
    2.5854   45.1961   51.2570 H   0  0  0  0  0  0
    2.8416   46.9029   51.4015 H   0  0  0  0  0  0
    0.6428   46.1264   52.3546 H   0  0  0  0  0  0
    1.5815   47.0521   53.4434 H   0  0  0  0  0  0
    1.1399   44.0442   53.4993 H   0  0  0  0  0  0
    0.6748   45.2279   54.7104 H   0  0  0  0  0  0
    2.7092   43.8475   55.3459 H   0  0  0  0  0  0
    2.9556   45.5551   55.4288 H   0  0  0  0  0  0
    4.9208   44.6063   54.3892 H   0  0  0  0  0  0
    3.9911   43.6323   53.3084 H   0  0  0  0  0  0
    4.2108   40.5699   46.4877 H   0  0  0  0  0  0
    3.1327   40.0939   48.6677 H   0  0  0  0  0  0
    4.1634   40.9006   50.7623 H   0  0  0  0  0  0
    6.3008   42.1012   50.7394 H   0  0  0  0  0  0
    8.2898   42.5561   47.8235 H   0  0  0  0  0  0
    6.3393   41.8654   46.4593 H   0  0  0  0  0  0
   11.5200   44.7341   50.2536 H   0  0  0  0  0  0
   11.5662   46.6643   52.1189 H   0  0  0  0  0  0
  1 14  2  0  0  0
  1 21  1  0  0  0
  1 22  1  0  0  0
  2 18  2  0  0  0
  2 19  1  0  0  0
  2 45  1  0  0  0
  3  4  1  0  0  0
  3 16  1  0  0  0
  3 25  1  0  0  0
  3 26  1  0  0  0
  4  5  1  0  0  0
  4  9  1  0  0  0
  4 27  1  0  0  0
  5  6  1  0  0  0
  5 28  1  0  0  0
  5 29  1  0  0  0
  6  7  1  0  0  0
  6 30  1  0  0  0
  6 31  1  0  0  0
  7  8  1  0  0  0
  7 32  1  0  0  0
  7 33  1  0  0  0
  8  9  1  0  0  0
  8 34  1  0  0  0
  8 35  1  0  0  0
  9 36  1  0  0  0
  9 37  1  0  0  0
 10 11  2  0  0  0
 10 24  1  0  0  0
 10 38  1  0  0  0
 11 12  1  0  0  0
 11 39  1  0  0  0
 12 13  2  0  0  0
 12 40  1  0  0  0
 13 23  1  0  0  0
 13 41  1  0  0  0
 14 15  1  0  0  0
 15 16  1  0  0  0
 15 17  2  0  0  0
 17 18  1  0  0  0
 17 20  1  0  0  0
 19 20  1  0  0  0
 19 44  1  0  0  0
 20 21  2  0  0  0
 22 23  1  0  0  0
 22 42  1  0  0  0
 23 24  2  0  0  0
 24 43  1  0  0  0
M  END
> <s_m_entry_id>
9

> <s_m_entry_name>
1H1Q.1

> <s_m_Source_Path>
/Users/sheenam/Downloads

> <s_m_Source_File>
1H1Q.mol2

> <i_m_Source_File_Index>
1

$$$$

Output

Output when running the above script in new conda environment.

/scratch/micromamba/envs/new/lib/python3.10/site-packages/smirnoff99frosst/smirnoff99frosst.py:11: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.
  from pkg_resources import resource_filename
rdkit version 2024.03.5
openmm version 8.2
parmed version 4.3.0
openff-interchange version 0.4.2
openff-toolkit version 0.16.9
openff-units version 0.2.1
Conda env name new
Potential Energy -385.61852136708023 kJ/mol

Output produced when running the above script in the old conda environment.

/scratch/micromamba/envs/old/lib/python3.10/site-packages/smirnoff99frosst/smirnoff99frosst.py:11: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.
  from pkg_resources import resource_filename
rdkit version 2024.03.6
openmm version 8.2
parmed version 4.3.0
openff-interchange version 0.3.18
openff-toolkit version 0.14.3
openff-units version 0.2.1
Conda env name old
Potential Energy -390.3161788158834 kJ/mol

Software versions

Please find below two minimal env.yaml I used to conda environments (via micromamba env create -f file.yaml)

name: old
channels:
  - conda-forge
  - nvidia
dependencies:

  - python=3.10
  - ambertools=23.6
  - pip
  - numpy <2
  - scipy
  - pandas
  - gputil
  - jax ~=0.4
  - jaxlib ~=0.4
  - ambertools=23.6
  - cudatoolkit=11.8.0
  - openmm=8.2.0
  - openff-toolkit=0.14.3
  - openff-units=0.2.1
  - rdkit
  - parmed

name: new
channels:
  - conda-forge
  - nvidia
dependencies:

  - python=3.10
  - ambertools=23.6
  - pip
  - numpy <2
  - scipy
  - pandas
  - gputil
  - jax ~=0.4
  - jaxlib ~=0.4
  - ambertools=23.6
  - cudatoolkit=11.8.0
  - openmm=8.2.0
  - openff-toolkit=0.16.9
  - openff-units=0.2.1
  - rdkit
  - parmed

[mattwthompson]

Interesting, having a look now

[mattwthompson]

I can narrow this down to some atoms being assigned slightly different charges:

$ diff new-system.xml old-system.xml | grep Particle                                                                 13:12:55
< 				<Particle eps=".359824" q=".9148777777777778" sig=".3399669508423535"/>
< 				<Particle eps=".359824" q=".38767777777777773" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q=".13337777777777776" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q="-.08272222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q="-.07492222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q="-.07392222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q="-.07642222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q="-.07392222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".4577296" q="-.07492222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".359824" q="-.12002222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".359824" q="-.13802222222222224" sig=".3399669508423535"/>
< 				<Particle eps=".359824" q="-.12002222222222222" sig=".3399669508423535"/>
< 				<Particle eps=".359824" q="-.13402222222222224" sig=".3399669508423535"/>
< 				<Particle eps=".7112800000000001" q="-.8380222222222222" sig=".32499985237759577"/>
< 				<Particle eps=".359824" q=".7615777777777778" sig=".3399669508423535"/>
< 				<Particle eps=".7112800000000001" q="-.4171222222222223" sig=".3000012343465779"/>
< 				<Particle eps=".359824" q="-.21322222222222223" sig=".3399669508423535"/>
< 				<Particle eps=".7112800000000001" q="-.5011222222222222" sig=".32499985237759577"/>
< 				<Particle eps=".7112800000000001" q="-.38202222222222226" sig=".32499985237759577"/>
< 				<Particle eps=".359824" q=".46877777777777774" sig=".3399669508423535"/>
< 				<Particle eps=".7112800000000001" q="-.7570222222222223" sig=".32499985237759577"/>
< 				<Particle eps=".7112800000000001" q="-.7033222222222223" sig=".32499985237759577"/>
< 				<Particle eps=".359824" q=".12557777777777776" sig=".3399669508423535"/>
< 				<Particle eps=".359824" q="-.13402222222222224" sig=".3399669508423535"/>
< 				<Particle eps=".06568879999999999" q=".06867777777777777" sig=".2471353044121301"/>
< 				<Particle eps=".06568879999999999" q=".06867777777777777" sig=".2471353044121301"/>
< 				<Particle eps=".06568879999999999" q=".05267777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".04767777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".04767777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".03867777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".03867777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".03717777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".03717777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".03867777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".03867777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".04767777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06568879999999999" q=".04767777777777777" sig=".2649532787749369"/>
< 				<Particle eps=".06276" q=".13297777777777778" sig=".25996424595335105"/>
< 				<Particle eps=".06276" q=".13297777777777778" sig=".25996424595335105"/>
< 				<Particle eps=".06276" q=".13297777777777778" sig=".25996424595335105"/>
< 				<Particle eps=".06276" q=".14297777777777776" sig=".25996424595335105"/>
< 				<Particle eps=".06568879999999999" q=".43677777777777776" sig=".10690784617684071"/>
< 				<Particle eps=".06276" q=".14297777777777776" sig=".25996424595335105"/>
< 				<Particle eps=".06568879999999999" q=".3176777777777777" sig=".10690784617684071"/>
< 				<Particle eps=".06276" q=".07377777777777778" sig=".24214627159054422"/>
> 				<Particle eps=".359824" q=".9138333333333334" sig=".3399669508423535"/>
> 				<Particle eps=".359824" q=".38763333333333333" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q=".1383333333333333" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q="-.09176666666666668" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q="-.07096666666666668" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q="-.07546666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q="-.07546666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q="-.07546666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".4577296" q="-.07096666666666668" sig=".3399669508423535"/>
> 				<Particle eps=".359824" q="-.12006666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".359824" q="-.1380666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".359824" q="-.12006666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".359824" q="-.1340666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".7112800000000001" q="-.8360666666666666" sig=".32499985237759577"/>
> 				<Particle eps=".359824" q=".7575333333333334" sig=".3399669508423535"/>
> 				<Particle eps=".7112800000000001" q="-.4161666666666667" sig=".3000012343465779"/>
> 				<Particle eps=".359824" q="-.2132666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".7112800000000001" q="-.5001666666666666" sig=".32499985237759577"/>
> 				<Particle eps=".7112800000000001" q="-.38206666666666667" sig=".32499985237759577"/>
> 				<Particle eps=".359824" q=".46873333333333334" sig=".3399669508423535"/>
> 				<Particle eps=".7112800000000001" q="-.7570666666666667" sig=".32499985237759577"/>
> 				<Particle eps=".7112800000000001" q="-.7033666666666667" sig=".32499985237759577"/>
> 				<Particle eps=".359824" q=".1265333333333333" sig=".3399669508423535"/>
> 				<Particle eps=".359824" q="-.1340666666666667" sig=".3399669508423535"/>
> 				<Particle eps=".06568879999999999" q=".06613333333333332" sig=".2471353044121301"/>
> 				<Particle eps=".06568879999999999" q=".06613333333333332" sig=".2471353044121301"/>
> 				<Particle eps=".06568879999999999" q=".06763333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".04488333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".04488333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".03888333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".03888333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".03713333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".03713333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".03888333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".03888333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".04488333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06568879999999999" q=".04488333333333332" sig=".2649532787749369"/>
> 				<Particle eps=".06276" q=".13293333333333332" sig=".25996424595335105"/>
> 				<Particle eps=".06276" q=".13293333333333332" sig=".25996424595335105"/>
> 				<Particle eps=".06276" q=".13293333333333332" sig=".25996424595335105"/>
> 				<Particle eps=".06276" q=".1429333333333333" sig=".25996424595335105"/>
> 				<Particle eps=".06568879999999999" q=".43673333333333336" sig=".10690784617684071"/>
> 				<Particle eps=".06276" q=".1429333333333333" sig=".25996424595335105"/>
> 				<Particle eps=".06568879999999999" q=".3176333333333333" sig=".10690784617684071"/>
> 				<Particle eps=".06276" q=".07373333333333333" sig=".24214627159054422"/>

This leads me to believe valence parameters are being assigned identically. The vdW parameters look identical as well. I'm still working on narrowing down the reason for the small discrepancy in charges; typically we might see subtle differences between the RDKit and OEChem because of ELF10 but that's clearly not the case here.

[mattwthompson]

For this ligand, the difference in energies happens to be because of a slight differences in the behavior of the RDKit. Let me explain and try not to type up a wall of text - but I am happy to elaborate and share code/files in follow-up.

With the open-source stack, Parsley and Sage use AmberTool's sqm for AM1-BCC charges. By default, the input conformer is thrown away, a new one is generated with the RDKit, and then passed to AmberTools¹. This flavor of AM1-BCC is conformer-dependent and we just saw the charges are slightly different, so I used the RDKit² to generate each in isolation and save them out to disk. I get an RMSD of about 1.5 Angstroms, which I intuit to be a moderate difference.

If I force both environments to use the RDKit 2024.03.5³, I get identical OpenMM XML files and the script reports identical energies (-385.61852136708046 kJ/mol).

Partial charges are notoriously fussy and, unfortunately, software-to-software differences on this scale are pretty common. @j-wags would be the point person to explain this better, I only know the headline there.

There's lots more that could be looked at here, and there are plenty of obvious caveats with this analysis (my machine is probably slightly different than yours, the ligand you're sharing may or may not be representative of the entire data set, etc.). But does this help you understand what's plausibly the cause of your behavior, and give you confidence that the software is behaving in line with expectations?

Happy to continue to help, of course!

Footnotes

1. See the relevant section of the SMIRNOFF spec for more ↩

2. This all happens in the OpenFF's wrappers of these toolkits, but we refer to the wrapper and underlying toolkit synonymously at times ↩

3. I couldn't solve both into 2024.03.6, for some reason, so I went with 2024.03.5 ↩

[j-wags]

Yes, what Matt said is 100% right - We want to give consistent formal charges, which is why we do the whole RDKit-conformer-generation thing in the first place (to ensure that, even if the user loads the same molecule in two different poses, or with nonsense coords that need to be minimized, we generate the same conformer for charge assignment so they get the same charges during simulation). However this approach has unavoidable issues like changes in the version of the conformer generator, and various other steps in the process.

This is generally a big pain and some collaborators recently put out a paper measuring exactly how painful it is. This has motivated us to just make an ML tool to assign charges (NAGL). We have a NAGL model that assigns AM1BCC-like charges extremely quickly, and it does not depend on conformers and should give the same charges to the same molecule every time. NAGL-assigned charges will actually be the default charge assignment method in our next force field release (openff-2.3.0, coming soon!), and you can substitute them for the slow, conformer-dependent AM1BCC charges in our existing force fields using the code from this notebook.

(Also, thanks for the top-notch issue report!)

[mattwthompson]

Concurred - this is one of the most thorough bug reports I've ever been sent, and it made my job as easy as it could be

[asood-alg]

@mattwthompson @j-wags

Thank you for your kind words and your help with this. Your explanation makes sense to me. So if I understand correctly, openff-interchange is behaving as intended and the discrepancy is due to partial charge assignment which is done in conformer dependent fashion, and the conformers produced by RDKit 2024.03.5 and RDKit 2024.03.6 are different.

I have some follow up questions / discussion points:

1. Mostly for my education, could you point me to the lines of code in interchange where the conformers are generated and partial charges are assigned. I would like to inspect conformers myself as well across different RDKit versions.
2. Do you think this discrepancy in conformers (I suspect this is likely ligand dependent) between different versions of RDKit 2024.03.X is a regression and is the issue worth raising with the RDKit devs ? Is there a recommended version of RDKit, that I should pin / use with openff ?
3. Thanks for the pointer to NAGL. It has been on the periphery of our todo list for a while now, and I think it might be time to move it up.

[mattwthompson]

1. Unfortunately, it's not a short path¹. Let's start by simplifying this and assume it's a SMIRNOFF forcefield, no OpenEye license is available, and the <ToolkitAM1BCC> section is ultimately used to assign partial charges². Interchange has a lot of bookkeepping inside of (and before getting to) SMIRNOFFElectrostaticsCollection.store_matches. If one has an excess of patience and spare time, they'll end up at a Molecule.assign_partial_charges call which was earlier set to use partial_charge_method="am1bcc". This is just in Interchange, though, which delegates out to the toolkit. That path starts here and ends up here. The call out to RDKit for conformer generation happens here and the direct interaction with RDKit starts here.

The toolkit bits can be isolated with just a few lines of code, though. I actually used this script to see what conformers and partial charges were generated by each environment (I think it was the RMSD between *_debug.sdf files that tipped me off to the root cause above):

from openff.toolkit import Molecule
import os

conda_env_name = os.path.basename(os.environ["CONDA_PREFIX"])

molecule = Molecule.from_file("ligands.sdf")
molecule.generate_conformers(n_conformers=1)  # just for saving out for inspection - this is NOT used in AM1-BCC assignment
molecule.assign_partial_charges(partial_charge_method="am1bcc")
molecule.to_file(f"{conda_env_name}_debug.sdf", file_format="sdf")

2. I'm not a medicinal chemist, but the conformers generated by each version look reasonable to my eye. I'd have a hard time saying one is more "correct" than the other. My sense is that conformer generation is part art, part science and that some differences between software versions isn't out of bounds.³ I'm happy to be corrected by cheminformatics experts here. And OpenFF doesn't pin to RDKit or have opinions on which versions are "correct" to use⁴. Jeff may chime in (but not until next week) with his hard-earned expertise on the impact of subtle partial charge differences, similar to the paper he linked above.

Footnotes

1. Mostly because the toolkit does a lot of things, including gracefully manage a lot of functionality from multiple wrapped programs with a unified API. Not easy! ↩

2. As distinct from i.e. library charges, pre-set charges, or NAGL charges ↩

3. This again motivates the conformer-independent partial charges from NAGL; if not for differences in partial charges, we could easily say that small differences in conformer generation are unlikely to cause energy-minimization with a given force field to end up at different structures. ↩

4. Anecdotally, differences between OEChem (which is used in fitting the force fields) and RDKit + AmberTools are non-trivial, so it's difficult to enforce differences between software versions/hardware/etc. ↩