Performance Optimization
or, how to get more Rowan for your dollar
As a frequent user of AI coding tools like Codex and Claude Code, I (Corin) like many others have become a follower of Thibault Sottiaux (“Tibo” on X), the head of Codex at OpenAI. There’s a lot to admire about how Tibo’s managed strategy and messaging for Codex. In particular, he’s been transparent about various Codex-related failures and performance regressions, fixing them publicly and resetting usage limits with reckless abandon. As a Codex user, it’s obvious that the product is getting dramatically more capable and efficient over time, and I trust that my Codex subscription will be better value two months from now than it is today.
While we don’t (yet) have a big red button that lets us reset everyone’s Rowan usage limits, we’re constantly looking for ways to make calculations faster so that customers can get more Rowan for their dollar. In this newsletter, I want to share a bunch of miscellaneous optimizations that we’ve recently incorporated into Rowan, with the goal of highlighting interesting performance optimizations that might otherwise go unnoticed.
There’s not much new science in this post, and the interface and results should generally stay the same for existing users. What should instead change is speed. Here are some rough estimates:
GPU4PySCF is more reliable, more scalable, and 3–10x faster.
g-xTB pKa prediction is 2–3x faster for large molecules.
Blood–brain-barrier-permeability prediction in the macroscopic pKa workflow is >10x faster for large molecules.
Analogue docking is >5x faster in general.
RBFE calculations are 2–3x faster on some systems.
Solubility calculations can now be run in groups, leading to >100x speedups on large numbers of calculations.
(And, as we shared in the newsletter from a few weeks ago, MD is about 2x faster than it used to be.)
The rest of the newsletter will go through these cases and share what we’ve done to improve performance. Where it makes sense, I’m using maraviroc as the example molecule because (1) it’s a structurally interesting molecule and (2) it’s emblematic of the sort of complex drug-like molecules that our industry users typically simulate.
Density-Functional Theory
While Rowan supports multiple DFT engines, by default we use GPU4PySCF for most DFT calculations. Recent GPU4PySCF improvements have allowed us to make DFT in Rowan noticeably faster. Hardcore DFT users may have noticed some issues recently—there have been a lot of GPU4PySCF releases (which is great, thanks GPU4PySCF team!) but we’ve found ourselves playing whack-a-mole with a few different bugs, sometimes leading to frustrating or inconsistent behavior for large systems.
We’ve spent a good amount of time over the past few weeks tracking these performance issues and have recently deployed a litany of fixes and improvements. At a high level, here’s what’s changed:
Various updates led to a version mismatch between GPU4PySCF and cuTENSOR, which GPU4PySCF uses for GPU-accelerated linear algebra. This meant that GPU4PySCF was silently falling back to a slower and less memory-efficient CuPy backend, leading to out-of-memory errors and longer runtimes. We’ve fixed this and added robust checks for this issue moving forward.
Rowan uses level shifting internally to improve SCF performance for metals and other difficult-to-converge systems, which was occasionally failing an automatic PySCF check at the end of SCF iterations. We now further relax the converged level-shifted density in such cases, which fixes these errors.
Earlier versions of PySCF and GPU4PySCF had unreliable or numerically incorrect analytical Hessians, forcing Rowan to fall back to significantly slower numerical Hessians in most cases. Recent updates have fixed these issues (thanks!), so Rowan now uses analytical Hessian calculations everywhere.
Rowan uses density fitting to accelerate DFT calculations, which requires use of an auxiliary one-electron basis set derived from the user-required basis set. Originally, Rowan was using an automatic even-tempered-Gaussian basis, which gives correct results but has more basis functions than needed, particularly for heavy elements. We’ve replaced these with the recommended JFIT or JKFIT auxiliary basis sets where possible, which again reduce memory needs and led to faster calculations.
We’re also now pre-compiling various just-in-time computed kernels for GPU4PySCF, preventing the slow startup times that users may have encountered previously.
These fixes have led to dramatic speedups. Starting from an ETKDG-initialized structure of maraviroc, an optimization and frequency calculation at the wB97X-3c level of theory took 3:09:56 before these updates. With these changes, the same calculation completed in 54:20, a greater-than-3x speedup. We’ve seen speedups of >10x in other cases, and previously impossible calculations that ran out of VRAM even on an H200 GPU can now complete successfully.
Changing the auxiliary basis does lead to slight numerical differences between old and new results. While for the most part these discrepancies are small, we advise users in the middle of projects to recompute energies using the newest release. If you want help migrating data over, please contact our team and we’ll be happy to help.
g-xTB pKa
We’ve significantly accelerated Rowan’s g-xTB pKa workflow. In a previous newsletter, we reported that using openconf for per-microstate conformer searches led to much faster and slightly better performance than CREST.
We’ve now applied a variety of additional optimizations to the conformer-optimization pipeline—e.g. reusing conformer ensembles across microstates, pre-optimizing with GFN-FF where possible, and eliminating needless CPCM-X & frequency calculations for low-weight conformers—which make pKa predictions faster and, on internal test sets, don’t impact results.
These speedups can be substantial for larger molecules. For maraviroc, the time to run g-xTB pKa predictions decreased from 34:17 to 11:30.
Blood–Brain-Barrier Permeability
Rowan’s macroscopic-pKa workflow can use the ESOL method to predict blood–brain-barrier permeability. To compute the ESOL value, we run a conformer search, optimize each conformer, and then look at the difference in energy between gas- and solution-phase conformers. For complex molecules, this could result in hundreds of individual conformer optimizations that didn’t end up meaningfully impacting the final ESOL calculation.
We’ve ported the conformer-clustering logic that we previously developed for our solvent-dependent-conformers workflow to this conformer search, eliminating needless conformer optimizations. This decreased the maraviroc runtime from 39:17 to 2:15 (almost 20x faster) without meaningfully affecting the predicted value (BBB score 0.340 vs 0.366, within expected variation due to conformer search).
Analogue Docking
Rowan’s analogue-docking workflow contains multiple levels of nested parallelism: a quick torsional Monte Carlo conformer search is run on each analogue, and all of the resultant poses are deduplicated and scored by short score-only Vina calls. Over an entire set of analogues, this means that thousands of individual Vina calls are made.
Earlier versions of Rowan’s analogue-docking workflow performed these calls serially using the same logic as our regular docking workflow. We’ve now sped up repeated Vina calls by judicious use of multiprocessing, since score-only calls don’t parallelize well, and by recycling the Meeko-prepared receptor file across different analogues. As a result, the 76-analogue OpenBind set that took 2:25:22 a few months ago (newsletter) now takes 22:52, a >6x speedup.
Free-Energy Perturbation
Since we launched FEP in March, we’ve been working to improve efficiency and performance. We’ve improved GPU utilization through smarter scheduling algorithms, and eliminated resource contention related to different levels of multiprocessing.
Taken together, these changes have substantially accelerated RBFE calculations run through Rowan. A CDK8 FEP calculation on 32 ligands that took 26 hours in February now only takes 9 hours to complete, for a total speedup of almost 3x.
Batched Solubility Predictions
Scientists often want to predict solubility of many molecules at once, a use case which has historically been somewhat challenging and inefficient in Rowan. Previously, individual workflows were scheduled, run, and saved independently, adding a layer of overhead to each workflow that made running tens of thousands of calculations more expensive than it needed to be.
We’re introducing a new way to run solubility calculations to address this issue: you can now submit groups of up to 5,000 solubility workflows that will run together on the same machine. This substantially reduces the per-workflow overhead; with the Kingfisher solubility method, 5,000 calculations can now complete in under two minutes, dramatically reducing credit usage and latency for users.
You can submit solubility calculations in groups with our new rowan-python method:
import rowan
smileses = ["CCO", "CC(=O)O", "c1ccccc1"]
workflows = rowan.submit_solubility_workflow_group(
initial_smileses=smileses,
method="kingfisher",
solvents=["water"],
temperatures=[298.15],
)
While we’re starting with just solubility, we anticipate adding similar functions for Rowan’s other low-cost workflows.
More from Our Team:
Choosing suitable poses for FEP is a well-known challenge encountered by teams trying to automate binding-affinity calculations. Zach’s latest post examines the effect of different pose-ranking methods and finds that simple docking scores performed best, giving results which are statistically indistinguishable from more complicated methods.
Several months ago, we hosted an agentic med-chem hackathon in which teams competed to propose binders to TBXT as potential chordoma therapies. We just got results back from the lab, and 6/12 compounds were confirmed hits! In a collaborative blog post with muni, we share what compounds ended up being hits, what strategies worked, and what we’ve learned from this experience.