Speedup for molecule isomorphism checking

[j-wags]

• Fix Topology.identical_molecule_groups is too slow #2035
  • This makes the reproducing case run on my machine in ~0.5 sec, compared to 11 min using the old stack
• Add tests
• Update docstrings/documentation, if applicable
• Lint codebase
• Update changelog

[codecov]

Codecov Report

❌ Patch coverage is 95.65217% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 82.69%. Comparing base (7febf6d) to head (e204d49).
⚠️ Report is 1 commits behind head on main.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mattwthompson]

Does this depend on the order of the data.neighbors(node) iterator (in problematic ways)? I will try to think of an antagonistic test case tomorrow, if possible

[j-wags]

Thanks, this is an absolutely filthy hack but I've been unable to think of edge cases that would trip it up. The order of the neighbors shouldn't matter since they're all chemically equivalent hydrogens, and we specify stereochemistry on the central atom using CIP rules which should be invariant to the ordering of the bonds/neighbors (as opposed to tying it to the ordering of bonds, where losing track of the Hs' identities could MAYBE scramble things in some complex way).

I'd love any other ideas you come up with, even if they're just smells that you can't solidify into test cases. This is for sure cooked if we ever get a H with two bonds or try to handle deuterium or something.

[mattwthompson]

So far I'm seeing a net improvement in some Interchange.to_x export times. I have not looked at anything beforehand (molecule loading, topology preparation, parameter assignment, partial charge assignment, etc.) nor is this a completely comprehensive analysis.¹

The two environments I used are my Interchange development environment (with this branch installed) and a second with only released versions of our software²

	OpenFE JACS set (vacuum)	Mixed solvent system	Ligand in water	Tim's polymers
GROMACS	No change	Marginally worse	Slightly better	Huge improvement
OpenMM	No change	Marginally worse	Somewhat better	No change

Footnotes

1. I have receipts for everything elsewhere if people want lots of logs files ↩

2. micromamba create --name released openff-toolkit seaborn polars tqdm matplotlib ↩

[j-wags]

A quick update here - I'm offline for the rest of this week and half of the next, but my plan is to come back around the 27th and try to prove to myself that this is a safe approach and put in tests to raise the alarm if a later change violates some assumption that this needs (no divalent H, no H isotopes, no negative atomic numbers, etc). If folks want to help out by thinking of edge cases/regressions, that could help me get through the QA process faster.

[hannaomi]

Some results using the faster_isomorphism branch with the highly polydisperse systems that were the use case in issue 1156 (trying to link this properly but it will only let me link the PR with that number).

The faster isomorphism branch has consistently lower create_interchange() runtimes compared to using off-toolkit v.0.17.0 when number of unique polymer chain components in the topology is increased.

Unclear to me what was causing that huge jump at >40 unique polymer chains, but it appears to have been fixed by the changes in faster_isomorphism.

For comparison, here is where I started when this issue was opened (toolkit v.0.16.8)

I can post some reproducing code for this benchmark if needed.

[mattwthompson]

Thanks @hannaomi - those results look great! The discontinuity is indeed confusing but in either case the scaling appears to remain linear and the performance is improved.

Outside the context of this PR and your benchmarks, we have a couple of other patches in Interchange in the pipelines which might help this even further - both creation and export. Based on some benchmarking I've done, I suspect most of the runtime is Interchange and not the toolkit - but that's not worth a deep dive right now, I don't think.