Tautomer generation speed up

[pechersky]

In the blog, it said

If there are any burning bottlenecks not present in the current set of functions, please do reach out.

In various modeling applications, for bookkeeping of molecules or for physiological-state modeling, one needs to do tautomer enumeration and canonicalization. That is a CPU intensive task that can take an arbitrary amount of time (proportional to complexity of the ligand). It would be great if it could be accelerated.

[scal444]

Thanks for the suggestion!

I looked into this a little, and it seems likely that substructure matching is the main bottleneck in this workflow (will run some perf analyses to double check). That's a topic we've avoided tackling due to the difficulty of reproducing RDKit's recursive query setup and the difficulty of implementing subgraph isomerism on the GPU.

Both of those difficulties are potentially solvable, or at least we could hopefully support enough of SMARTS to cover most usecases. But it would be an experimental development and would take quite some time to even see if it's feasible and if we can get good speedups.

Still, we get a lot of requests for substructure searching so it might be worth the effort to work on it. I'll discuss with my team about our priorities and get back to you.

[pechersky]

Sounds good! Happy to communicate/collaborate. In terms of substructure matching, it's true that it is a very daunting task in the general case. I've had some attempts at more narrow optimizing via trying to port/copy of the steps into the Nauty framework, which is very optimized for that type of work.

[scal444]

Update here - we're working on substruct search. Won't support tautomer workflow directly for the first release but we can experiment once the general APIs are out.

[pechersky]

Great, thanks! You might want to take a look at the VF2 part of the codebase -- that's what's used in the tautomer workflow also. cf: rdkit/rdkit#9046

[scal444]

Basic substruct search was released as part of v0.4. We don't have immediate plans to re-work tautomer enumeration on top of it but feel free to experiment and let us know if we have any missing features that would block that integration.

Will still keep this open in case we decide to tackle it - but it would be direct-copying a lot of rdkit code that we'd then have to maintain against upstream updates, so not sure if we want it to sit in nvmolkit at this time.

[scal444]

Another update - I did some deeper profiling and it turns out the substructure search is not a huge bottleneck (more like 10%), it's the repeated smiles read/write/sanitization as new enumerations are spun off. At least with a few datasets I tried.

Speedups to mol reading/writing/sanitization aren't part of the nvmolkit scope, these can't really be ported to the GPU effectively without a tremendous effort. We have some upstream work to RDKit trying to improve the core data structures that might cut down on this timing, but closing this issue for now.

[pechersky]

FYI, no need for code changes or response, just for context.

I've been making inroads at optimizing the codepath for tautomerization. Example are rdkit#9134 which does not have API changes, and the larger rdkit#9046 which does reduce sanitization, at the expense of some API changes and some changes in what canonical means. I've also recently had merges of canonicalization of kekulization.

Thank you for the RDMol reference. In my profiling on the optimized (unmerged) branch, something like that would help. The other remaining rate limiting steps become transforms that are hard to prefilter for, like the 1,7 transformation.