Heterogeneous catalysis, crystal growth, intercalation, and electron exchange all happen at the surfaces of materials. Different cuts of these materials expose different faces, and those faces alter the kinetics and thermodynamics of many processes. Which faces of the material persist depends on surface energy (γ): only the lowest-γ faces dominate the morphology.

The new subscriber-only surface-energy workflow on Rowan simplifies the process of finding the lowest-energy faces: automatically enumerating possible cuts, optimizing the resulting slabs, and calculating the resulting surface energies and Wulff construction.

Surface energy in detail

Surface energy (γ) is the energy per unit area required to cleave a crystal along a plane. For close-packed FCC metals like rhodium, palladium, and platinum, the (111) face is most commonly exposed. Other crystals favor different faces, and multiple faces can be exposed at the same time, each with its own chemistry. Minimizing the number of bonds cut per unit area tends to lead to lower γ, but certain cuts can reveal unfavorable terraces and ridges or create polar surfaces whose electrostatic energy diverges. Determining which surfaces are likely to be exposed is thus an important first step in elucidating the downstream chemical activity of a material.

Rowan’s surface-energy workflow automates the process of cutting and optimizing all possible slabs. First, it identifies all potential cuts up to a given Miller index (a notation indicating what face is exposed) and deduplicates symmetry-equivalent cuts (e.g. (111) and (-111)). It then cuts ≈10 Å-thick slabs with ≈10 Å of vacuum on each side; slabs that cannot be constructed with stoichiometric cuts and symmetric surfaces are discarded. The remaining slabs are optimized, with any surface reconstruction indicated by a message appended to the workflow. The relative energies of the slabs are strong indicators of the relative likelihood of formation, and the constructed slabs can themselves be used for further calculations of surface properties.

Wulff constructions

The total surface energy for a particle is a product of the average γ and the total surface area. A sphere minimizes the total surface area, but exposes many high-energy surfaces, while a cube allows the material to be constructed from the lowest-energy symmetry-equivalent faces, but exposes a greater surface area. For crystals where a single surface is significantly lower in energy than others, a single face will dominate the resulting particle. For a species with numerous faces that have low-lying surface energies, the particle will be rounder.

This is formalized in the Wulff construction, which yields the shape that minimizes the combined surface energy of all faces, and is the thermodynamically preferred shape when edge and corner effects are ignored.

NaCl favors a cubic form since the (100) face and its five symmetry-equivalent faces are significantly lower in energy than other faces. During crystal growth, this leads to the formation of cubic crystals, as deviations from (100) are higher in energy and thus disfavored. The effect is strong enough that this is visible at the macroscopic scale, with halite crystals often forming a series of cubes.

Nanoparticles and heterogeneous catalysis

Nanoparticles often approximate the Wulff construction, and faces differ in activity. In heterogeneous catalysis, some surfaces can be inert, while others are highly active. Thus, the relative proportion of each face is important for predicting the reactivity. In 2020, Hao et al. published an analysis of CO dissociation on Rh nanoparticles, requiring many careful DFT calculations to build the Wulff construction and determine the dissociation pathways. This work can quickly be replicated using the UMA-S-1.2-OMat neural network potential and the surface energy and double-ended TS search workflows.

CO preferentially binds to certain faces, and each face presents numerous potential binding positions. The (100) face favors CO binding in the bridging position, while the (111) face favors binding in the top position.

C–O bond dissociation is more favorable on the (100) surface since the hollow site gives the carbon fourfold coordination. This dissociation can be modeled with CI-DNEB using the double-ended TS-search workflow and subsequent TS optimization.

The true rate of dissociation is temperature- and pressure-dependent, and microkinetics is needed to include inter-site interactions in the kinetics and thermodynamics of the dissociation. Real-world catalysts are also not perfect surfaces or nanoparticles, but are instead pockmarked with adatoms, kinks, and islands, all of which can contribute to the overall rate of the reaction.

Subscribers can start using our surface-energy workflow today. We plan to continue adding new tools for materials and heterogeneous catalysis to go with the phonons, UV-Vis, and periodic TS-search workflows we added this summer. If any of this interests you, we’d love to hear from you, please reach out.

When a molecule absorbs light from its surroundings, this can induce molecular motion, change the electronic structure, eject electrons, or re-emit the light (and often a combination of the above). Microwaves excite rotational motion and are used by microwave ovens to heat your food. Infrared induces vibrational motion, and is responsible for the sun’s warmth. Visible and UV light induce electronic excitations which are responsible for the color of dyes, the activity of solar cells, and the degradation of polymers. X-rays can rip core electrons out, generating radicals that can cause DNA damage.

Rowan has long supported the prediction of molecular vibrations and the resulting IR spectra, but the computation of electronic excitations is significantly more involved and requires excited-state methods. We are excited to introduce TDDFT on Rowan, providing access to UV-Vis absorbance and fluorescence prediction as well as excited-state geometry optimization. For more on the specifics of how TDDFT works, you can read our technical blog on the method. For a worked example of using TDDFT to predict the color of azo dyes, you can read a blog post by our summer intern Isaiah.

Absorbance

When light of the correct energy hits a molecule, it can excite the molecule to a new electronic state wherein the electron configuration differs. Once excited, the light may be immediately re-emitted at the same energy (Rayleigh scattering), re-emitted with a slight shift (Raman scattering), or the molecule can remain in the excited state for an extended period of time and change geometry (potentially emitting from the new geometry). The wavelengths at which a molecule absorbs can be predicted with TDDFT.

Rowan runs TDDFT with GPU4PySCF on H200 GPUs, providing significant speedups over CPU-based implementations. To run TDDFT starting from an optimized ground-state geometry:

• Open the basic calculation workflow, and select the TDDFT mode.

• Select single-point energy (the “Energy” task).

• Pick a functional, basis set, and solvent; ωB97X-D3/def2-TZVP is a great place to start.

• Choose how many roots to compute; we recommend 10 for small molecules (<30 atoms) and 20–50 for larger molecules.

Molecules that absorb in the visible range can be useful as dyes, and their color is dependent on the visible light that the molecule does not absorb. Single-point TDDFT calculations can provide a useful approximation of shifts in the absorbance peak (λ_max) when modifying dyes, but care should be taken when reporting absolute λ_max values (see an in-depth way of handling this for a large number of dyes in Isaiah’s blog post). Errors in λ_max are often due to a combination of:

• XC functional error,

• lack of vibronic effects,

• self-interaction error,

• the adiabatic approximation, and

• solvation effects.

If you are interested in running more accurate UV-Vis absorbance calculations at scale, we’d be happy to chat about the ways to improve your calculations; please reach out.

Fluoresence

When molecules are first excited, they are at a non-optimal geometry on the excited-state surface. If the light is not immediately re-emitted, vibrational relaxation quickly occurs (<10^–12 seconds), producing a new geometry. When the molecule fluoresces from the new geometry (10^–6–10^–9 seconds) and drops down to the ground electronic state, it emits less energy than it absorbed since it lands on a different section of the ground-state potential-energy surface (observed as a Stokes shift in fluorescence spectroscopy).

Fluorescence is significantly harder to model than absorbance due to the variable excited state lifetimes, which are affected by the rates of:

• Internal conversions (IC) - conversion between electronic states of the same multiplicity

• Intersystem crossing (ISC) - conversion between electronic states of the different multiplicity

• Vibrational relaxation (VR) - relaxation of vibrationally excited (“hot”) molecules down to their lowest vibrational state

• Phosphorescence - emission from an excited state of a different multiplicity than the ground state

Internal conversion and vibrational relaxation are typically fast compared to fluorescence, and intersystem crossing is strongly dependent on the potential for spin-orbit coupling, which is more pronounced in heavier elements. Vibrational relaxation down to the ground state can occur through intersystem crossing, avoiding the fluorescence path entirely.

Light-induced rearrangements

When molecules relax after being excited to a new electronic state, significant rearrangement can be induced. Tetrafluoroethylene’s geometry changes from flat (D₂h) to twisted (D₂d) in its first excited state; similar rotations cause the cis–trans isomerizations that allow retinal in our eyes to detect light. Photoacids like triphenylsulfonium triflate break internal bonds and rearrange to produce a strong acid upon irradiation. Photochromic species shift the wavelengths of light they can absorb, allowing for things like photochromic glasses to act as sunglasses outside. Polymers with significant unsaturation will often produce radicals under UV irradiation, leading to a radical cascade and photodegradation; this leads to the yellowing of styrene–butadiene paints and the need for photostabilizers.

In spiropyrans, excitation by UV light leads to C–O bond cleavage and a flattening of the species into a merocyanine. This can be modeled via optimization of the first excited state with TDDFT. Once the excited-state optimized species relaxes back to the ground state, merocyanine is formed. This species has significantly more absorbance in the visible range due to its extended π system. Modified spiropyrans can shift the absorption wavelength to different colors, and can be used as photochromic indicators.

Conclusion

TDDFT can be used to model numerous systems beyond what has already been shown, including:

• Photodegradation of polymers

• OLED emission spectra, degradation, and quenching

• Solar cell sensitivity

• Biomolecular UV response

You can model all of these today on the Rowan platform. Since TDDFT is significantly slower than ground-state DFT, we recommend subscribing if you plan to run more than a couple UV-Vis curves or if you plan to run excited-state optimizations. TDDFT is available in both our API and via the GUI, and the latter is great for large-scale screening.

If you are interested in running calculations at scale, running more accurate excited-states methods like EOM-CCSD, or modeling advanced properties like circular dichroism, please get in touch; we’d be happy to chat.

We’re excited to introduce a new phonon workflow as our intern Raphael closes out his summer internship work helping us add materials capabilities to the Rowan platform. This workflow can be used to determine a material’s phonon band structure and zone-center modes, predict its response to infrared (IR) and Raman spectroscopy, and examine its thermal properties.

Phonons

Atoms in a material are never still. Even at absolute zero, they have zero-point vibrational energy that smears them around their lattice points. As the temperature rises, excited vibrational modes further displace the atoms. The coupling of the atomic vibrational motion leads to collective motion, termed phonons. As the size of the crystal increases and the unit cells couple, an effectively continuous spectrum of phonons is formed (unlike the discrete spectra of molecules).

Phonons mediate many properties of materials, carrying heat, transmitting sound, and scattering the electrons that carry current. They can be excited by the absorption of light (typically infrared absorption), scatter light when interacting with it (Raman scattering), and mediate the Cooper-pair formation that underlies conventional superconductivity. Our latest workflow computes phonon band structures, thermal properties, and zone-center modes, providing scientists with information about structural stability, preferred polymorphs, and thermal properties.

Band Structure and Density of States

The spectrum of phonons in a material is referred to as the band structure, and the density and identity of these bands vary throughout the Brillouin zone (the primitive cell in reciprocal space). The three lowest-frequency modes are the acoustic modes, arising from the long-range, nearly phase-symmetric vibration of atoms. These phonons correspond to rigid translations of the whole crystal and can propagate sound. The slopes of these modes near the center of the Brillouin zone (also called the gamma point, Γ) indicate how quickly sound travels through the material. Along high-symmetry directions near Γ, the modes neatly decompose into one longitudinal (compression) mode and two transverse (shear) modes.

The remaining branches are often significantly higher in energy, and arise from the out-of-phase motions inside a unit cell. These are termed optical modes due to their interactions with light. Polar modes (where the dipole changes) give rise to IR absorption, while non-polar modes (where the polarizability changes) give rise to Raman scattering.

The highest frequency mode usually reflects the stiffest individual bond or the lightest atom; diamond has one of the highest frequencies of any bulk solid at 1,332 cm^–1. The lowest modes dominate low-temperature heat capacity and thermal conductivity. Exceedingly low modes may indicate structural instability, while imaginary modes indicate that a displacement along this mode would lower the material’s energy (these can arise from symmetry-breaking motion that quasi-second-order optimizers don’t follow). Small imaginary modes can also be artifacts of an incompletely converged optimization or numerical instability.

Zone-Center Modes and IR/Raman

At Γ (the center of the Brillouin zone), phonons are referred to as zone-center modes (also called gamma-point phonons). While the acoustic modes are 0 at Γ, the optical modes have non-zero energies that arise from the out-of-phase motion of the atoms within the cell. These modes can be excited by light (typically infrared or visible), and the activity is similar to that seen in individual molecules. The modes can similarly be decomposed based on their point-group symmetry, providing an indication of whether they are active under the electric-dipole (IR) or electric-dipole–dipole-polarizability (Raman) approximations.

Thermal Properties

As the thermal energy rises above absolute zero, excited states of phonons are accessed. The available excited states generally increase with temperature, and thus the specific heat capacity (the amount of thermal energy absorbed per unit increase in temperature) increases. How fast a material approaches its classical heat capacity value depends on the frequencies of its lattice vibrations, which in turn depend on both lattice stiffness and atomic masses.

As a representative example, CsCl and CsBr are both in the 221 space group, with two atoms per primitive cell. The phonon spectra are similar in structure, but the CsBr frequencies are about two thirds of the CsCl frequencies across the whole spectrum due to the higher mass of Br. Due to the more thermally accessible modes, CsBr approaches the classical heat capacity limit more quickly than CsCl.

Apart from our phonon workflow, we’ve also put a lot of work into improving our periodic optimizer, including the addition of variable-cell TS search, improved constraint–cell coupling, and we derivation of the gradient from the step map instead of masked-strain filters. We’re excited to continue building to meet the needs of our materials science user base. We expect we’ll have more to share on this front soon!

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.

LogP

The logarithm of the octanol–water partition coefficient, logP, is a crucial quantity for small-molecule therapeutics. LogP measures a compound’s lipophilicity or “fattiness,” which correlates with that compound’s ability to dissolve in water, be absorbed through the intestinal wall, and permeate cell membranes. These concerns mean that a well-balanced logP is crucial for an effective drug; greasy molecules with a high logP are poorly soluble and can bind or accumulate in weird ways, while polar molecules with a low logP are often poorly bioavailable and cell-permeable.

Our new logP workflow includes three methods for calculating/predicting logP: RDKit’s simple Crippen logP model, a Chemprop D-MPNN model trained on experimental data, and a physics-based method that uses COSMO-RS to predict logP. Here’s a few details about the first two methods:

• RDKit’s Crippen logP model is a venerable atom-contribution-based method that’s been a mainstay of industry cheminformatics for decades.

• Our Chemprop D-MPNN method is a machine-learning model trained on the recently released SangsterLogP dataset of 23K unique experimental logP values.

In our hands, both of these methods achieve high levels of accuracy on drug-like molecules. The graphs below show their performance on the held-out prospective set from the SangsterLogP paper, with the Chemprop model having a slight edge in performance.

Like all empirical methods, we expect that both the Chemprop and Crippen models will perform better in typical drug-like regions of chemical space and struggle for exotic species.

Our third method is a physics-based approach using COSMO-RS. COSMO-RS is a method that combines quantum chemistry and thermodynamics to predict properties like solubility and activity coefficients for solvents and mixtures. Our COSMO-RS-based logP-prediction workflow generally follows the protocol developed by Wilcken and co-workers at Novartis and mirrors our solvent-dependent conformers workflow. For each input molecule:

• Conformers are generated with openconf.

• Each conformer is optimized with GFN2-xTB/ALPB(Water) // g-xtb/CPCM-X(Water).

• Conformers are then clustered based on simple descriptors like like solvent-accessible surface area, polar surface area, radius of gyration, etc.

• The lowest energy conformers from each cluster are then subjected to a BP86/def2-TZVPD DFT single-point calculation, which is used as the input to COSMO-RS.

• The COSMO-RS results are used to evaluate each conformer’s free energy of solvation in both water and octanol to yield a calculated logP.

These calculations are much slower than the two above methods, but we expect the results to be far more robust to complex, out-of-distribution molecules. COSMO-RS-based workflows have previously done well in blinded logP-prediction challenges (e.g.). In our benchmarking, we’ve noticed solid performance on drug-like molecules and are interested in pushing the boundaries of these predictions.

API Key Budgets

With our agentic future looming nigh, we’re continuing to build the controls necessary to give an agent access to Rowan in a stress-free way. We’ve previously given keys strict controls so that keys can only read & write data (no deletion power) or even only read data, and API keys can be issued that are scoped to a single project within your Rowan account.

Our latest addition is the ability to give an API key a budget. Jobs started using this API key will count towards this budget, and when the API key’s budget is consumed, all the associated jobs will be stopped.

This means you can give an agent (or a person) an API key and let them run wild without worrying about any surprise billing. These budgets can be set in the GUI via the API keys page:

API key budgets can also be managed programmatically through Rowan’s Python API. When creating an API key, you can specify a budget parameter in the create_api_key call. Budgets can later be modified using update_api_key_budget. Both operations require a master API key with the can_manage_api_keys permission.

User Survey

Help shape the future of Rowan by taking our summer 2026 user survey! We really value hearing feedback from our users and want to make Rowan as useful as possible for scientists working in chemical R&D.

We expect the survey to take 5–10 minutes. After you complete it, we’ll add 500 credits to your Rowan account; these credits will expire one year after they are issued. Credits are offered in exchange for thoughtful, good-faith responses. Submissions that contain no substantive feedback or appear to have been completed at random will not be eligible.

This survey will close end of day on August 14, 2026.

More from Our Team

• Corin gave AI agents challenging NMR spectra from the literature and asked them to figure out the structure. The agents were run at different reasoning levels and some were given access to Rowan’s NMR workflow. We found that use of the external NMR tool led to a dramatic improvement in agent performance. Additionally, tool integration helped the agents make the most of their reasoning level. Read the full post.

  

• Nick wrote a post that outlines different conformer-generation and conformer-search methods. If you’re curious about how to find conformers or need help choosing the right tool for your work, read “How to Find Conformers.”

• Ari wrote a practical overview of how to use computational chemistry to model reactions for the unfamiliar. If you’re not sure how to find a guess TS, confirm you’ve found the right TS, or calculate accurate barrier heights, check out “How to Model a Reaction.”

• Finally, we put a guide together for developers building Rowan integrations into their user-facing applications. If you’re building a platform for your internal users at your company or an AI-for-science platform, this post outlines how to best leverage Rowan’s data model and API key features. Read the guide here.

We’re excited to launch Rowan’s nuclear-magnetic-resonance (NMR) workflow, which uses the new MagNET ML model to predict ¹H and ¹³C NMR spectra. This workflow is the result of a multi-year collaboration with many other teams—Eugene Kwan and co-workers at Merck, the Coley and Smidt groups at MIT, the Liu group at Harvard, the Paton group at Colorado State, and others—and has been in private beta for about a year here at Rowan. We’ve also released the MagNET preprint, “Chemical Shift Prediction Beyond the Electronic Structure Limit,” on ChemRxiv, along with open weights and code on HuggingFace and GitHub.

Background

NMR spectroscopy is a mainstay of the organic chemistry lab. ¹H and ¹³C spectra are required for all new compounds reported in the literature, and it’s typical for practicing organic chemists to obtain 10 or more NMR spectra per day, sometimes many more. While simple NMR spectra are often completely human-interpretable, computational NMR predictions are widely used for complex cases like assigning regioisomers, figuring out which diastereomer is which, and structural elucidation of metabolites or other obscure chemical species.

Unfortunately, predicting NMR spectra computationally is difficult. The state-of-the-art way to predict NMR entails:

• Running a careful conformational search

• Optimizing each output conformer with density-functional theory (DFT)

• Running per-conformer NMR predictions, also with DFT

• Boltzmann-averaging the output shieldings and apply empirical scaling to generate a final predicted spectrum

This sequence must be repeated for each structural candidate being considered, and it’s not uncommon for accurate NMR predictions to take “days or even weeks of wallclock time” (preprint). Quicker methods (like the heuristic approach used in ChemDraw) exist, but aren’t accurate enough to be useful for most non-trivial structural identifications.

While NNPs and other advancements in low-cost computational chemistry have made the initial conformer-search part of this workflow orders of magnitude faster, the immense cost of predicting NMR with DFT means that overall NMR prediction remains slow. Each NMR prediction is comparable in cost to a Hessian or frequency calculation and can easily take hours per conformer.

MagNET: Fast NMR Predictions via ML

MagNET is a drop-in replacement for DFT that directly addresses this bottleneck. We ran millions of DFT calculations to generate a large dataset of predicting NMR shieldings and then trained an ML model to predict these values. Long-time newsletter readers might think this story sounds familiar; like an NNP, MagNET uses an equivariant graph-transformer architecture (specifically, Equiformer v2), but predicts isotropic NMR shieldings from compound geometries rather than the electronic energy.

In practice, this means that MagNET is as good or better than DFT-based NMR predictions, while running orders of magnitude faster. On the delta-22 benchmark set, MagNET approaches the performance of quadruple-zeta basis sets and specialized NMR functionals, handily outperforming typical DFT methods:

MagNET is fast enough to be used in a variety of contexts which are prohibitively expensive for DFT-based NMR. Here’s two applications that we highlight in the paper:

• MagNET can be used to model rovibrational corrections to NMR constants, which requires computing the NMR spectrum of many frames from a quasiclassical MD trajectory (see Kwan and Liu, 2015).

• MagNET can also be used to model explicit-solvent corrections to NMR by modeling large solvent clusters derived from explicit-solvent MD trajectories. This produces noticeably better results for a variety of solvents, particularly aromatic solvents like benzene and toluene.

There’s a lot more to discuss here—why errors are flat across so many levels of theory, where remaining errors come from, how we trained this model, what’s in the dataset, and so on—but this blog is the wrong place! For more scientific details and discussions, see the preprint.

Predicting NMR Spectra in Rowan

MagNET-powered NMR predictions can be run in Rowan through the new NMR workflow. Users simply submit a chemical structure and a solvent; under the hood, Rowan runs a conformer search with openconf, deduplicates and optimizes the conformers with AIMNet2, and then computes solvent-corrected NMR shieldings for each conformer using MagNET. The final Boltzmann-weighted results are automatically plotted as ¹H and ¹³C spectra, with symmetric protons combined. (Sadly, J-coupling constants aren’t computed.)

If you’re curious about what atoms generate a given peak, you can simply click on the peak on the spectrum and the corresponding atoms will be highlighted on the structure.

Rowan automatically includes solvent effects in the conformer weighting process and the subsequent NMR shieldings, making it possible to quickly predict how spectra will change between solvents. Here’s the predicted ¹H NMR spectra of the common laboratory solvent DMA in both chloroform and benzene:

The computed shifts in both solvents match literature values well, and MagNET correctly predicts that the two methyl groups are better separated in benzene than in chloroform. If you find yourself with overlapping peaks in chloroform, consider predicting a few different solvents to find one that resolves the peaks! It’s faster (and less wasteful) than just trying different solvents.

Rowan’s NMR workflow is also good for more complex structure-elucidation tasks. One common use of NMR prediction is assignment of diastereomers; the popular CP3 method from Smith and Goodman involves computing the NMR shifts of all potential diasteromers and then comparing the experimental differences between shifts to computed differences between shifts.

To test MagNET’s ability to distinguish diastereomers, we reproduced a published DFT-based CP3 assignment of cinchona alkaloid diastereomers (reference). Higher CP3 scores indicate better agreement; for the first spectrum in the paper, Rowan-predicted NMR shieldings gave a ¹H CP3 score of 0.763 for the correct diastereomer (spectrum) and –0.901 for the incorrect diastereomer (spectrum), closely matching the published DFT values of 0.797 and –0.913 and clearly predicting the correct stereochemistry. Comparing the two NMR calculations makes the spectral differences obvious in Rowan:

Rowan’s NMR workflow takes just a minute or two and is immediately useful for laboratory chemists who regularly work with NMR spectra. Professor Michel Gravel from the University of Saskatchewan, one of our early NMR users, writes:

The NMR workflow in Rowan is very helpful for my research group. We routinely use it to ascertain the products of a reaction, to assign relative configuration, and to elucidate unknown structures. In our experience, the MAE is on par with the most accurate DFT methods. The workflow is so seamless and the interface so user-friendly that we have adopted it to complement our undergraduate lab experiments.

After years of work, we’re excited to finally release this to all Rowan users. We expect that NMR prediction will be routinely useful to a wide range of organic chemists, and we’re looking forward to seeing how easy access to high-accuracy NMR prediction can speed up their work or enable new projects. If you know an organic chemist who records NMR spectra regularly, consider telling them about Rowan!

Testing Rowan-Enabled Agents on DrugDiscoveryBench

Early this month, Scale Labs and Phylo released DrugDiscoveryBench, a benchmark designed to evaluate how well agents can perform early-stage drug discovery tasks. We ran a subset of this benchmark with Rowan-enabled agents, making use of our Python SDK and skill, to see how this would affect performance.

While our sample size was small, we found that Rowan tool use generally improved agents’ ability to successfully complete drug discovery tasks. Rowan-enabled agents also reached correct answers more consistently across repeated runs of the same task than agents relying on direct reasoning. The biggest pitfall was discoverability; agents with Rowan tools often used direct reasoning or ran crude local simulations instead of calling the relevant Rowan tool, which frequently led to a failed task

We’re excited to keep improving Rowan-agent integration to the make scientific agents more effective. If you would like to integrate Rowan with your agents, use our Python SDK, our skill, and please reach out to us! Read the full analysis on our blog.

We’re releasing a completely rewritten reaction toolkit today, coinciding with our presentation about it at the Gordon Research Conference on “Molecular Discovery and Simulation in the AI Era” in Barcelona this week. In brief:

• We’ve rewritten everything from scratch to be more robust and performant, using only NumPy and SciPy as dependencies.

• We’ve added the minimum-energy-path-generation methods GSM and CI-DNEB to our existing FSM.

• We’ve also added geodesic and IDPP interpolation methods.

• Our IRC code now implements the HPC/EulerPC method and is significantly faster.

• Both of these codes have been updated to support both periodic and non-periodic systems.

Here’s a bit more on the science behind this, what we’ve changed, and the impact that this has for practical tasks in Rowan. (Also see the end of this newsletter for details on our new Vicena integration and two new blog posts on protein–ligand complexes.)

Transition-State Searching

Locating a transition state (TS) for a reaction is a difficult problem. Even when the precise mechanism is known, properly aligning the forming and breaking bonds at the correct distances takes considerable practice. TS optimizers have small convergence radii, and small errors in placement can lead to the optimization failing.

Worse, small changes in the substituents can shift the transition state earlier or later, causing a good guess to fail when an R-group is swapped. This difficulty is compounded by the cost of the quantum-chemical methods commonly used for optimizations. TS optimization starts and ends with the calculation of a Hessian (matrix of mixed second derivatives); a semi-numerical Hessian on a 100-atom system requires 300 gradient calls. Thus, computational chemists typically spend significant amounts of time setting up a guess geometry; having to repeat the calculation multiple times is costly and time-consuming.

Even with the advent of low-cost methods like NNPs, good guess geometries are still hard to come by. Simply interpolating between the reactants and products will shove atoms through each other on their way to their final destination, producing nonsense. Smart interpolation methods such as IDPP and geodesic can steer the reactions around obvious clashes and avoid breaking/forming too many bonds, while interpolation in redundant internal coordinates can better express the large-scale motions that are happening (e.g. backbone rotations). However, even the best interpolation methods still produce highly strained species. Information from the true potential-energy surface is needed to help the path avoid high-energy intermediates. Methods of doing so are often divided into two classes: string methods and band methods.

Band methods stretch an interpolation across the surface, sample images along it, and then optimize these images subject to spring forces from adjacent images (preventing images from collapsing into the minima). Nudged elastic band (NEB) is the dominant method; it adds spring forces between images and projects out spring forces orthogonal to the tangent at the image that would otherwise pull atoms off the path. Images are relaxed under these constraints, approximating the true path. Many variants exist, including doubly-nudged NEB (DNEB) and climbing-image (CI-NEB), which accelerate the determination of the path.

In contrast, string-based methods iteratively grow strings from each endpoint towards the opposite endpoint. They take a step along the interpolation, place a node, and optimize the nodes orthogonal to the existing string. This process is repeated until the string ends meet. The growing-string method (GSM) loosely optimizes the whole of each string every time new nodes are added, and performs a tighter post-connection sweep. The freezing-string method (FSM) eschews post-placement optimization, only loosely optimizing new nodes before adding them to the string. FSM produces paths that do not follow the minimum-energy path and are often significantly more strained, but it is often an order of magnitude cheaper than GSM, and doesn’t risk nodes sliding back into the endpoint region.

We’ve implemented FSM and GSM with BFGS Hessian updates on each node and copy the Hessian from the previous node when adding new nodes, accelerating optimization. We included both climbing image and double nudging in our NEB implementation, and we use the FIRE optimizer to accelerate band convergence due to the non-conservative band forces. This rewrite also allows us to treat periodic and non-periodic systems on equal footing and tightly integrate the code with our existing optimizer and NNP infrastructure, allowing us to realize significant improvements in speed and robustness. For a longer write-up on how double-ended TS search methods work, see our blog from last year.

Intrinsic Reaction Coordinates (IRC)

Once a putative transition state has been found, it is important to use an IRC to verify that it truly connects the reactants and products. It is not uncommon for a proposed transition state to instead connect two minima that are nothing like the reactants or products, or connect one conformer to another. IRCs are particularly important for complex or highly congested reactions, where multiple branching paths could be possible, but we hope that they can become standard practice for all published transition states.

IRCs follow the mass-weighted minimum-energy path (the same path as a perfectly damped molecular-dynamics trajectory). Our IRC code implements the Hessian-based predictor–corrector (HPC/EulerPC) algorithm of Hratchian & Schlegel in mass-weighted Cartesian coordinates:

1. Compute the Hessian at the TS.

2. Displace along the imaginary mode.

3. Find the point on the hypersphere that is the lowest in energy:

   1. Build a distance-weighted interpolant (DWI) by taking the energy and gradient at a predictor step.

   2. Use the DWI surface to analytically determine the true minimum on the hypersphere.

4. Determine the length along the path via the DWI.

5. Repeat until max steps or a minimum is reached.

6. Repeat in the opposite direction.

This method is effectively 4th order, improving on our previous IRC workflow which used the 2nd-order Gonzalez–Schlegel (GS2) IRC from geomeTRIC. The use of Cartesian coordinates as opposed to TRIC avoids the difficulties from back-transforming internal coordinates, allowing it to quickly solve for the next step and to work well for periodic systems.

We’ve also added a few additional features to our workflow to simplify the job of a chemist. The IRC workflow provides initial TS optimization, endpoint optimization, and Hessian refinement instead of full Hessian recompute when the Bofill-update Hessian becomes ill-conditioned. We’ve also added support for periodic systems and support a wide variety of NNPs, semiempirical methods, and even DFT.

Benchmarks

The Baker TS set is commonly used for benchmarking TS-optimization and TS-search methods. It comprises 25 small-molecule transition states generated with HF/3-21G. We re-optimized the TSs with UMA-S-1.2-OMol, generated endpoints with IRCs, and benchmarked how various search and interpolation combos performed.

Our geodesic interpolation method (implemented following Zhu, Thompson, and Martínez) outperforms all other interpolations on the Baker set. It penalizes bond rearrangement, favoring interpolations that generate the fewest bond changes (technically, it finds the geodesic on a Riemannian manifold with a Morse-scale interatomic-distance metric). The systems in this benchmark set are too small to see the benefits of our redundant internal coordinates and often fail the iterative back transformation due to the tightly curved nature of the paths (it has a comparative advantage for large systems with dihedral-driven motion, e.g. biphenyl rotations). FSM is an order of magnitude faster than other methods, with only marginally reduced accuracy. It can produce highly strained species (see figure below), but much of the strain is orthogonal to the true reaction coordinate, and thus the subsequent partitioned rational-function TS optimization quickly optimizes it out.

These methods also work well for larger systems, or when significant rearrangement occurs. The oxidative addition of methyl bromide to a gold complex splits the methyl group and bromine and places them on opposite ends of the complex. While FSM produces a highly strained initial guess (>100 kcal/mol above the TS), the subsequent optimization is still able to locate the TS.

Reactions in periodic systems often involve complex motions that cannot simply be decomposed into bond stretches or bends. Along with the large expense of periodic DFT gradients, TS search is often difficult to perform. However, geodesic interpolation does an excellent job of steering atoms, while avoiding the back-transformation difficulties inherent in redundant internal coordinates. For an interstitial carbon migration in BCC Fe, FSM and NEB trace similar paths and find the same transition state, with FSM completing significantly faster.

We’ve added numerous graphical updates to our double-ended TS-search and IRC workflows, including the ability to compare workflows, stream the results in near real time without the save call blocking the main compute thread, and included the post-search TS optimization and frequencies as tabs in the GUI. All of these search, interpolation, and IRC methods are now available to our users in both the GUI and via our rowan-python API.

We hope to continue improving our reaction modeling tools and build new ones for modeling reactivity at scale. If you are interested in reaction modeling at scale or find any reactions where these TS-search methods consistently fail, please reach out. We are always trying to improve our tools, and establishing a compendium of difficult systems is helpful for continuing to make them better.

Vicena Integration

We’re excited to share that Rowan now integrates with Vicena, an agentic scientific workspace that (in their words) brings research tools, evidence, and results into one continuing project, so researchers can focus on the scientific question rather than managing each tool separately. Rowan’s suite of simulation tools integrates naturally with Vicena’s search and reasoning capabilities; you can read more on specific use cases on Vicena’s website.

Here’s what Vicena CEO Mehdi Farzanepour has to say on the integration:

The value of bringing Rowan and Vicena together is that researchers get the depth and reproducibility of computational simulations alongside the breadth and flexibility of a unified agentic research. This helps close the research loop by connecting ideas, literature, data, calculations, and results, then using what is learned to refine the question and decide what to do next.

As part of the integration, Mehdi is offering Rowan users a 50% discount for 4 months on subscriptions to Vicena. If you’re interested, you can sign up for Vicena with code LETSDOMORESCIENCE (valid through September 30th).

Blogs

We’ve also recently published two blogs that might be of interest to our readers in drug discovery:

• “What to Do With a Pose,” an introduction to how to analyze protein–ligand poses in Rowan. We’ve noticed a lot of early Rowan users get stuck at this stage so we decided to compile all our advice and relevant features into one place.

• Some case studies benchmarking Rowan’s hydration-site-analysis functionality, demonstrating that our implementation recovers known hydration sites from the literature and showing off compatibility with larger molecular glues. This hydration-site analysis feature is now live for all Rowan subscribers in the pose-analysis MD workflow!

Until next time, happy computing!

We’re excited to share a variety of updates to Rowan’s structure-based drug discovery toolkit today. As we work to support more and more biotech/pharma teams, we’ve been finding lots of ways to increase our platform’s capabilities and depth.

(To help keep things manageable, this newsletter is organized in pipeline order, starting with protein preparation and ending with FEP.)

Protein Preparation and Protein pKa

Getting a crystal structure ready for simulation (whether docking, molecular dynamics, or FEP) is no easy task. Protein structures deposited in the PDB are often missing residues from flexible sections of a polymer chain as well as atoms from flexible side chains (not to mention hydrogens). The limitations of crystallographic methods mean there’s always work that needs to be done before a protein is simulation ready.

This is the problem of protein preparation; we previously offered a solution to this problem with PDBFixer, a set of tools built to get proteins ready for molecular dynamics (MD) simulations.

Today, we’re releasing a new workflow aimed at improving this process. At a high level, the workflow does a three-step process:

First, we add missing residues and any other missing heavy atoms. To add missing atoms, we support PDBFixer (as previously) as well as Boltz-2. When Boltz-2 is selected, we refold all the polymer chains using the input structure as a template. We then run an MD relaxation restrained to the input structure to enforce stronger template adherence. Co-folding models like Boltz are great at filling in missing flexible regions with plausible guesses, enabling preparation of difficult systems that PDBFixer struggles to prepare.

Next, we add hydrogens. To predict the per-residue protonation states, we support OpenMM’s Modeller (as previously) as well as the protonate_utils package from Pat Walters, which builds on the Hydride package. We’re interested in adding more protein-pKa methods in the near future.

Finally, we optimize hydrogen positions, iteratively flipping polymer side chains to avoid any donor–donor and acceptor–acceptor hydrogen-bond clashes. The flipping is followed by a quick hydrogen-only MM relaxation to ensure that the workflow returns a fully MD-ready system.

Gnina and Covalent Docking

We’ve also added a new docking engine, Gnina. Unlike the empirical physics-based scoring functions used in most docking programs (like Vina), Gnina scores poses with a convolutional neural network trained on experimental protein-ligand structures. In practice, this makes Gnina somewhat slower and more accurate than other docking programs: a variety of benchmarks have shown that Gnina outperforms Vina and other docking methods at pose retrieval and binder enrichment (see e.g. 1, 2, 3, 4).

Gnina also supports covalent docking, which can be used to model the docking of compounds that form a covalent bond with a protein. In practice, this means a user must additionally specify the atom in the ligand (the warhead atom) and the atom on the targeted residue to run covalent docking—Gnina will link these atoms together to generate the initial docked pose before running additional conformation-exploration steps. (You can read more about how this works in the Gnina 1.3 publication.)

Gnina can be run through Rowan’s docking workflows by selecting “Gnina” in the docking-settings dropdown. For covalent docking, input the atom indices of the reactive protein and ligand atoms; for non-covalent docking, leave these fields blank.

The “covalent docking” process modeled by Gnina and other non-covalent docking methods is not fully physical and produces a single hybrid score, rather than the multistep process of binding and bond formation undergone by real covalent inhibitors. We’re working on a QM-based method to simulate the individual mechanistic steps of covalent drug binding, which we expect to be more physical and to better capture warhead SAR than covalent docking; if this is of interest to you, reach out to discuss more with our team.

Co-Folding Non-Canonical Amino Acids and Nucleotides

It’s now possible to run co-folding with non-canonical residues and nucleotides. These can be added directly into an input protein sequence and are available with all 3 co-folding models in Rowan (Boltz, OpenFold, and Chai).

To run co-folding with a non-canonical residue/nucleotide, simply include the desired PDB Chemical Component Dictionary (CCD) code in parentheses in the protein sequence: for instance, the sequence “AGA(SEP)G” requests the alanine–glycine–alanine–(O-phosphoserine)–glycine pentapeptide.

Use of CCD codes allows co-folding methods to model D amino acids, methylated residues, different terminal caps, phosphorylation, and many more biochemical processes of interest to scientists and drug hunters. For more on the CCD and how to find CCD codes for your non-canonical residue/nucleotide, see this article.

MM/GBSA Single Points

We’ve added the ability to refine poses with molecular mechanics and generalized-Born-surface-area implicit-solvent calculations (MM/GBSA for short). For docking, analogue docking, and protein–ligand co-folding, Rowan now optimizes all ligand poses using MM/GBSA implicit-solvent calculations and reports the final single-point MM/GBSA interaction energy. We’re doing this for a few reasons:

• Poses generated by docking and co-folding are often unreliable or unphysical, and a quick MM/GBSA optimization can lead to dramatically more physical poses. (Previous Rowan pose refinement was ligand-only; this approach takes protein–ligand interactions into account.)

• The MM/GBSA single-point energy also serves as an external sanity check on poses. While docking and co-folding will often find a way to put a pose somewhere when requested, poor poses often have negligible or even positive interaction energy.

• Running these MM/GBSA optimizations also makes the systems much better behaved for downstream simulations, including MD and SAPT interaction analysis.

(Note that MM/GBSA interaction energies are not an effective way to predict binding affinity! However, they can be useful in ranking poses or triaging bad binders.)

MM/GBSA optimizations are run when users select “Local opt. and MM/GBSA” on the docking, analogue docking, and protein-ligand co-folding workflows.

Molecular Dynamics (MD) Speed Improvements

As more customers run MD workloads through Rowan, we’ve been working to make sure that our MD is as performant as possible. Increasing the timestep used for MD is one of the easiest ways to increase performance. To prevent numerical error, the timestep is typically required to be about an order-of-magnitude less than the fastest motion in the system. An O–H bond has a vibrational period of about 10 fs, implying that the MD timestep must be 1 fs or less.

This timestep can be increased through a technique called hydrogen-mass repartitioning (HMR), where the hydrogen mass is artificially increased to slow the bond vibration and allow for longer MD timesteps. Rowan previously used a hydrogen mass of 1.5 Daltons, allowing for 2 fs timestep. We’ve now changed the default hydrogen mass to 3 Daltons and the default timestep to 4 fs, resulting in a 2x increase in MD speed. Users can now tune these settings themselves if they prefer to disable HMR and use shorter timesteps.

In real life, this translates to dramatically faster MD runtimes. On a dasatinib•ABL kinase system (PDB 2GQG) with 55,517 atoms, Rowan was able to solvate, parameterize, minimize, equilibrate, and run a 10-ns MD simulation in 18 minutes total, reaching speeds of >1 µs/day on our standard L40S GPU hardware. We aim to make it routine to run short MD simulations on structures from docking, co-folding, or experiment, and will continue to look for ways to make these simulations faster and cheaper.

More MD Analysis

We’re also adding more outputs to Rowan’s protein MD and pose-analysis MD workflows, with the goal of making it easier to quickly gain useful structural insights. Here’s what we’ve added:

• MM/GBSA. Rowan now reports MM/GBSA interaction energies for protein–ligand trajectories, making it easier to compare poses while accounting for solvent effects. Average MM/GBSA scores can be used as an endpoint-based binding-affinity prediction method; these scores are almost always quantitatively incorrect, but can sometimes be very useful for quickly ranking binders before running FEP calculations. (See our post comparing binding-affinity methods for more details.)

• Radius of gyration. Rowan now reports the isotropic radius of gyration along trajectories, giving a simple readout of protein compactness and large-scale conformational change.

• SASA and polar SASA. Rowan also now computes total and polar solvent-accessible surface area (SASA), helping track changes in solvent exposure and buried area during MD simulations.

• Trajectory clustering. Geometrical clustering of trajectory frames is a convenient way to analyze protein conformational motion. Users can specify a fixed number of clusters to use k-means clustering or provide an RMSD threshold for Butina-like frame clustering—once computed, cluster centroids can be downloaded, and the change on cluster can be viewed as a function of time to understand transition timescales.

• RMSF. Per-residue root-mean-squared fluctuation values are now calculated for proteins in trajectory post-processing, which can be used to highlight flexible loops and stable regions. Highly mobile regions (like loops or disordered regions) typically have high RMSF values, while regions that are rigid or relatively frozen have low RMSF values.

• Hydration-site analysis. We’re also releasing a preview of Rowan’s hydration-site analysis feature, which detects what regions of the binding interface are most occupied by waters, how many unique waters pass through these sites, and whether waters at these mediate hydrogen bonds between protein atoms and ligand atoms (water bridges). This is a big feature and we’re planning to release more on this—including benchmarks and case studies—but subscribing Rowan users can run this starting today.

These properties can be viewed through new tabs and graphs in Rowan’s existing MD trajectory workflow.

Synthetic RBFE Intermediates

While RBFE calculations are a powerful way to accurately predict relative binding affinities, they require high overlap between a series. Modifications that look simple to a chemist (switching alkyl groups, adding or removing substituents, and so on) can sometimes lead to very difficult alchemical transformations, which in turn makes FEP slow and inaccurate.

Rowan FEP can now automatically identify “missing” compounds from an RBFE map based on maximum-common-substructure analysis and substituent enumeration, and automatically add these compounds to the graph:

This technique follows recent work from Linde Schoenmaker and co-workers, and can be enabled by selecting “Generate intermediate ligands” on the workflow submission screen.

While these sorts of synthetic intermediates are rarely useful on carefully prepared FEP benchmark sets, where there’s already good overlap between the ligands under study, we expect that this will be helpful in real-world use cases with more diverse chemotypes.

FEP Resubmission

In real-world lead optimization, scientists often go through rapid iterative design cycles. A medicinal chemist might design 20 analogues, simulate them with FEP, and then want to simulate another 20 analogues based on the results from the first set. Unfortunately, as discussed above, RBFE simulations work better on large sets of closely related compounds—so getting accurate results for the second set of analogues often requires re-running the first set of analogues, doubling the cost and runtime of the simulation.

Rowan FEP now allows users to resubmit finished FEP runs and add or remove ligands without re-running previously completed legs. This allows a few different useful features:

• Iteratively adding ligands. If you’ve already run a big RBFE graph and want to add a few more ligands, you previously had to re-run the entire graph. Now, you can simply resubmit, add the new ligands, and run only the handful of legs needed to connect these ligands to the rest of the graph.

• Removing bad ligands or poses. If a few of the ligands proved problematic or there were poorly converged legs, you can resubmit and remove these ligands to quickly recalculate the resulting well-behaved graph.

This feature was requested by a lot of our early FEP users, and we think it enables faster and more natural integration of FEP into real-world design cycles.

To enable this feature, simply resubmit an existing RBFE run to Rowan’s RBFE graph workflow. The previous FEP run will appear as a “seed graph” which serves as a template for the new run: the graph can be modified or deleted as desired. (The original FEP run will be saved and unchanged, allowing for clean record-keeping and audit trails.)

We’re excited to explore further ways to integrate FEP more naturally into existing drug-discovery workflows and make it possible to run FEP routinely at scale—if you’re interested in exploring this with our team, please reach out.

Molecules and materials often contain atoms that are identical except for rotations, translations, or reflections. Identifying these symmetry elements is useful for understanding the properties of the structure; entire classes are taught in graduate school to identify point groups and space groups and to help determine the corresponding properties (many a computational chemist has a cherished copy of Cotton’s Chemical Applications of Group Theory lying around somewhere).

Symmetry is often used to:

• simplify electronic structure calculations: many matrix elements and integrals must be zero due to symmetry considerations, thus simplifying calculations;

• inform spectral interpretation: IR-active vibrations transform as one of the Cartesian coordinates (x, y, or z) under the dipole selection rule;

• determine rotational spectral line spacing and relative intensities; and

• correct overcounting of entropy from the ideal-gas, rigid-rotor harmonic-oscillator (RRHO) approximation when a molecule has proper rotational symmetry elements (Cₙ axes, etc.).

Previously, the Rowan platform used the pymsymm package for computing point-group symmetry corrections to RRHO. Since it was written in C and didn’t support periodic systems, it was going to be difficult to extend with various features we were interested in. We therefore rewrote our point-group code in Python (achieving nearly the same speed as the original C code, without the risk of segfaults). For the 230 space groups of periodic systems, we added spglib. Now, molecules and crystals have their symmetry attached, and it can be viewed in the basic calculation workflow.

Molecules are often imported and drawn with imperfect symmetry, and now they can be symmetrized in the structure builder, allowing users to quickly fix nearly symmetric geometries.

Symmetry labels have also been added to orbitals in the electronic properties workflow for easier identification and use in chemistry classes.

XRD

For crystal structures, the X-ray diffraction pattern of the material is a standard fingerprint, as the height and positioning of the peaks indicate which of the 230 space groups it could belong to. When X-rays hit a crystal, the X-rays are absorbed and then re-emitted by the electrons surrounding each atom (Thomson scattering). If X-rays are shone on the crystal from various angles, the constructive and destructive interference patterns generated in the scattering can be used to infer the symmetry of the crystal (Bragg’s law: nλ = 2d sin θ).

The X-ray diffraction pattern can be directly predicted from the material’s structure and is useful for identifying materials, especially polymorphs. Real samples will have defects, mixtures of phases, preferred orientation, temperature effects, and broadened peaks, making the observed pattern slightly different, but they often align well with the predicted XRD pattern.

Carbon has numerous allotropes (single-element polymorphs) and the major ones have strikingly different XRD patterns. Changing from cubic diamond to lonsdaleite (hexagonal diamond) markedly lowers the crystal symmetry from the high-symmetry cubic space group Fd-3m to the hexagonal P6₃/mmc, which breaks equivalences among lattice planes and results in many more distinct XRD peaks.

Band Structures and Density of States

While XRD probes the positions of the nuclei and the resulting symmetry, we can also compute the electronic structure of a crystal. The periodic analogs of molecular orbitals are the band structure and density of states, which govern conductivity, optical absorption, reactivity, and more. These are shaped by the crystal’s lattice, bonding, and the way the electronic wavefunction repeats through space.

The band gap is the separation between the valence band maximum (VBM) and conduction band minimum (CBM); the periodic counterpart of the HOMO–LUMO gap. Its size and location determine the material’s electronic and optical behavior. A direct gap occurs when the VBM and CBM sit at the same point in the band structure, and an indirect gap occurs when they sit at different points. Direct-gap materials conserve momentum during electron–hole recombination and emit light efficiently, making them ideal for optoelectronics; indirect-gap materials are poor emitters, so charge carriers travel farther before recombining, which is useful in semiconductors.

Carbon nanotubes illustrate how geometry alone can flip this behavior. A nanotube is a sheet of graphene rolled into a cylinder, and the rolling direction changes which electronic states are available around the circumference, even though the atoms and bonding are identical. Two types of nanotubes are armchair and zigzag nanotubes.

Zigzag nanotubes are rolled along one of graphene primitive lattice vector direction (n,0), while armchair nanotubes are rolled along the sum of the two primitive lattice vectors (n,n). This zone-folding changes how graphene’s electronic bands align after rolling: all armchair nanotubes are metallic (zero or very small band gap), while zigzag nanotubes are metallic when n is a multiple of 3 and semiconducting otherwise.

Subtle geometric differences influence the electronic properties not only in carbon nanotubes but across a wide range of materials. For instance, VO₂ undergoes a dramatic metal–insulator transition between its low-temperature monoclinic (insulating) and high-temperature rutile (metallic) structures, accompanied by significant changes in its electronic structure. More broadly, entire fields such as twistronics, straintronics, and the study of topological semimetals exploit how small changes in geometry can dramatically alter band structures, density of states, and conductivity.

Elastic Tensor

While XRD characterizes a material’s atomic arrangement and band structures characterize a material’s electronic structure, the elastic tensor characterizes a material’s response to mechanical stress. The full tensor is a 6×6 matrix, and each entry C_i,j relates an applied stress to the resulting strain (deformation) in the elastic regime, together describing the stiffness and compressibility of the material.

A few scalar properties distill the full tensor into intuitive quantities: the bulk modulus (K) measures resistance to compression, the shear modulus (G) measures resistance to shearing, and their ratio, Pugh’s ratio K/G, is a reliable predictor of ductility. Materials with K/G > 1.75 tend to deform plastically before fracturing where those with lower values tend to cleave brittlely.

Silicon is a textbook brittle material: high stiffness and a Pugh’s ratio of 1.40, well below the ductility threshold. By contrast, gold has a Pugh’s ratio above 1.75, reflecting the ability of its metallic bonds to redistribute stress before fracture.

The elastic tensor also encodes directional anisotropy; a cubic crystal like silicon is nearly isotropic (C₁₁ ≈ C₂₂ ≈ C₃₃ and C₄₄ ≈ C₅₅ ≈ C₆₆), while lower-symmetry materials can be orders of magnitude stiffer along one axis than another. This directional information, often invisible to scalar moduli alone, matters for designing layered coatings, piezoelectrics, and materials under directional loads.

We are excited to see how these new workflows will be used in materials discovery pipelines, and have several more materials workflows in progress. If you work in the materials space, we’d be happy to chat about what you would like to see next on our platform, or how you can integrate our workflows to your existing discovery pipelines via rowan-python.

Rowan is a business that’s enabled by open-source scientific code. Packages like the RDKit, xTB, GPU4PySCF, and TMD (among others) are core to what we do, and we aim to give back to the open-source community both by contributing to existing open-source projects and creating new ones where we perceive gaps.

We’ve previously shared about some of the open-source projects that we’ve developed (Egret, PyPermm), help maintain (CoSIMS), or contribute to (ML-FSM). Today, we want to highlight a few of the new open-source projects we’ve been working on recently: a new conformer-generation package (”openconf”), a method for converting XYZ coordinates into RDKit molecules (”steamroll”), and a fast way for Butina-splitting large datasets (”Chalcedon”).

openconf: Rapid Monte Carlo–Based Conformer Generation

Most complex molecules can populate many different conformations, and finding the relevant conformers for new molecules is a big problem in molecule simulation. To date, Rowan has mainly relied on two methods for conformer generation:

• ETKDG, implemented in the RDKit, uses an experimental distance geometry–based method to embed molecules into 3D space based on their topology. (There are a few related variants here: KDG without experimental torsional information, ETKDGv3 which performs better for small rings & macrocycles, and so on.)

• iMTD-GC, implemented in CREST, uses iterated metadynamics and genetic crossing in combination with xTB methods to sample configurational space before identifying distinct minima.

While we’re big fans of both of these methods (and the science behind them), neither is perfect for all of our use cases at Rowan.

ETKDG often misses conformers or generates high-energy conformers for large systems (e.g. PROTACs) and has additional random pathologies (e.g. a curious preference for twist boats over chairs). While these problems can be ameliorated by generating thousands of conformers with ETKDG and then deduplicating, this can become quite slow (and a large majority of the replicas often converge on the same few conformers).

In contrast, iMTD-GC works well if you use quite careful settings, but struggles to generate high-quality ensembles for drug-like molecules with “quick” settings. Additionally, we’ve often run into issues with segfaults and other stochastic system errors in CREST, which creates issues when running calculations at scale through Rowan.

After a few years of fighting these issues and struggling to robustly get good performance in high-throughput contexts, we decided to bite the bullet and build our own conformer-generation method. Rather than trying to completely replace ETKDG or iMTD-GC for all applications, we aimed to quickly generate diverse and reasonable conformer ensembles for drug-like molecules that we could use in downstream applications like docking, pKa prediction, strain estimation, and so forth.

The result of this project is openconf, an open-source Monte Carlo–based conformer-generation package that builds atop the RDKit to provide physically reasonable conformer ensembles as quickly as possible. While we’re not the first people to explore Monte Carlo as a way to generate conformer ensembles (far from it), we think openconf is a nice addition to the modern open-source conformer-generation landscape. It’s written in modern Python, has only a few dependencies, and can be easily installed using your favorite Python package manager.

How openconf Works

openconf uses Monte Carlo moves to quickly explore conformational space. To ensure that reasonable conformers can be found even for complex systems, openconf implements a variety of Monte Carlo moves:

• Single- and multi-torsion: rotate around one or more rotatable bonds

• Correlated torsion: rotate a few adjacent bonds simultaneously

• Global shake: move a majority of the rotors all at once to escape local minima

• Ring flip: reflect e.g. a cyclohexane ring from one chair conformation to its mirror image

• Crankshaft: rotate an arc of ring atoms around the axis connecting two anchor atoms

• Kinematic inverse closure: rotate a macrocyclic ring bond and then uses cyclic coordinate descent to solve for the remaining ring torsional angles.

• Macrocyclic amide flips: convert ring amides between cis and trans conformers and re-close the rest of the ring (this becomes important for cyclic peptides)

The main openconf loop takes a pool of ETKDG-generated seeds and adds new conformers to the pool by iteratively applying the above moves and optimizing the output conformers using MMFF94. The success rate of each move is tracked, allowing openconf to adaptively adjust move probability, and convergence is tracked to enable early stopping for simple systems. (Ongoing deduplication of the conformer pool is key here; to improve performance, we’ve added batching to PRISM Pruner that makes deduplication c. 15x faster.)

openconf also works for inorganic and organometallic complexes, including lanthanides: UFF is used instead of MMFF94 and restraints are added to prevent metal–ligand dissociation. (Performance is still a bit flaky for some inorganic complexes; we hope to improve this in the future.)

Performance

In practice, openconf generates large and diverse ensembles more quickly than either ETKDG or iMTD-GC. While openconf is slower than ETKDG at generating 10 conformers, since the pool and seed overhead dominates, openconf becomes noticeably faster at 50+ conformers. Benchmarking on experimental datasets like OpenEye Iridium also confirms that openconf matches or outperforms ETKDG at the same budget for flexible drug-like molecules.

We’ve already been using openconf within Rowan for generating FEP input poses (see our previous newsletter), and we’ve now integrated openconf into many more parts of our platform. For Rowan’s physics-based pKa methods (employing AIMNet2 and g-xTB), we’ve found that openconf leads to lower errors and noticeably faster performance than either ETKDG or iMTD-GC. On a sample set of 16 drug-like molecules, openconf-based pKa prediction was over 4x faster than ETKDG-based pKa prediction (190 s for openconf vs 846 s for ETKDG) while giving lower mean error and fewer outliers.

We’ve also looked into using openconf-based ensembles for logP(octanol/water) prediction using Rowan’s solvent-dependent-conformer workflow, following precedent from Novartis on physics-based methods for logP prediction. We found that openconf runs 2 times faster than our previous iMTD-GC-based settings while giving virtually identical results (below, left), producing final logP predictions in line with those reported previously (below, right).

Macrocycles

Macrocycles are challenging for many conformer-search methods. Unlike typical drug-like molecules, macrocyclic conformations are connected by highly coordinated motions of the ring system. While these conformational changes can be described in terms of torsional rotations, they often require many dihedral angles to move simultaneously. To address this challenge, openconf incorporates several macrocycle-specific Monte Carlo moves (as detailed above). These specialized moves substantially improve sampling relative to naïve torsional perturbations and enable openconf to discover many macrocyclic conformations that would otherwise be challenging to discover efficiently.

Even with these enhancements, though, macrocycles remain challenging. To improve macrocycle performance further, openconf automatically expands the energy window and includes an optional low-mode conformational search routine. This technique uses the low-energy vibrational modes of the molecular Hessian to explore new conformational basins—since the lowest modes often describe collective molecular “breathing” distortions, exploring along these modes is a handy way to discover new minima that aren’t easily accessed through few-torsion operations (like most macrocycle moves).

These additions allow openconf to rapidly build diverse macrocyclic conformational ensembles; running a conformer search on the macrocyclic pan-KRAS inhibitor AMG 410 took only 12 seconds and generated 177 unique conformers, 20 of which are overlaid here. While some low-energy conformers differ only in rotation of peripheral groups, larger ring flips and perturbations are also important.

How to Run openconf

It’s straightforward to run openconf on your own projects. Simply run uv pip install openconf and start generating conformers:

from rdkit import Chem
from openconf import generate_conformers

# From SMILES
mol = Chem.MolFromSmiles("CCCCc1ccccc1")
ensemble = generate_conformers(mol)

print(f"Generated {ensemble.n_conformers} conformers")
print(ensemble.summary())

# Save to SDF
ensemble.to_sdf("output.sdf")

# Or XYZ
ensemble.to_xyz("output.xyz")

openconf is now the default for Rowan’s conformer-search and solvent-dependent-conformers workflows. Other methods, including ETKDG and iMTD-GC, can still be accessed through the conformer-generator dropdown.

We aim to make openconf an integral part of the open-source scientific ecosystem, not just a Rowan-owned project, and we’re excited to collaborate with other teams on benchmarking and improving the code. If you or someone you know uses an existing conformer-search method, consider trying out openconf and seeing how it compares; if you find any failures, please leave an issue or open a PR on GitHub!

steamroll

We’ve been steadily improving steamroll, our package that generates RDKit molecules and bond orders from XYZ coordinates. We’ve recently integrated code from Jan Jensen and co-workers that works for transition-metal-containing structures and extended their approach to cover lanthanides and actinides too. In practice, steamroll has become much more reliable and no longer freaks out with e.g. propellanes like it used to.

from steamroll.steamroll import SteamrollConversionError, to_rdkit

atomic_numbers: list[float] = ...
coordinates: list[float] = ...
charge: int = 0

try:
    rdkit_molecule = to_rdkit(atomic_numbers, coordinates, charge=charge, remove_Hs=True)
except SteamrollConversionError as e:
    print("Conversion to RDKit failed!")

If you find yourself wanting to convert .xyz files into 2D graph representations, check out steamroll! And, as with openconf, please leave an issue if you find a molecule that can’t be converted. We’ve already found (and fixed) many pathological 2D–3D conversions through Rowan, but more testing is always better for this kind of software.

Chalcedon

We’ve also developed a fast, memory-efficient package for Butina clustering and splitting chemical data after finding existing methods to be slow and impractical for large datasets on previous projects. Our method, Chalcedon, is an order-of-magnitude faster than existing implementations and reformulates the Butina-clustering algorithm to scale linearly in memory instead of quadratically. All performance improvements are made using BLAS through NumPy, making the package dependency-light. We hope to extend this package to include efficient implementations of other clustering and similarity methods as the need arises.

Read more in our blog post announcing Chalcedon from a few weeks ago.

All three of these projects are related to requests we originally made in our call for open-source projects last September. If you’re looking for new open-source chemistry projects to contribute to, consider contributing to one of the projects in that post, making a PR on one of our open projects, or reaching out to our team! We’re always happy to chat about what we think would be useful for the field.

OpenFold3

Today, we’re adding support for OpenFold3 (technically “OpenFold3-preview2”), an open-source reproduction of DeepMind’s AlphaFold-3 co-folding model developed by the OpenFold consortium.

OpenFold3 supports protein, nucleic acid, and small-molecule systems, and can run either with Rowan-generated MSAs or in single-sequence mode. It also supports generating multiple diffusion samples from a single prediction run.

We’re excited about OpenFold3 for a few reasons:

• It’s a genuinely different model. If Boltz-2 or Chai-1 struggle with your system, OpenFold3 gives you another state-of-the-art option to try.

• It can outperform Chai-1 and Boltz-2, particularly on targets that are less similar to structures seen during training.

• Generating multiple samples is much cheaper than in many other diffusion-based models. OpenFold3 produces five samples in roughly the same amount of time required to generate a single sample, making it practical to explore multiple candidate structures.

• Its accuracy approaches AlphaFold 3 on protein–protein, protein–DNA, and protein–RNA complexes.

OpenFold3 runs can be requested by selecting “OpenFold3-preview” as your model on the protein–ligand co-folding submit page:

Co-Folding with Templates

You can now provide structural templates for Boltz-2 and OpenFold3 predictions. In Boltz-2, templates can optionally be reinforced using physics-based potentials, with a configurable maximum-distance parameter that controls how closely the prediction follows the supplied template.

Templates can be provided either by uploading a structure file or by entering a PDB ID at the bottom of the co-folding submission page:

The effect of a template can vary considerably, ranging from a soft structural prior to a nearly fixed scaffold.

For Boltz-2, template adherence generally increases when physics-based potentials are enabled and the maximum-distance parameter is set to a smaller value. Disabling MSA generation can also encourage the model to follow the supplied template more closely, as discussed in this thread.

OpenFold3’s user-supplied template support was added recently and has not yet been included in an official release (although you can run it through Rowan). There are still some known limitations around template adherence; we hope this feature will improve over the coming months.

Overlay Protein Structures

To make it easier to judge template adherence and compare co-folding predictions, you can now overlay protein structures in Rowan’s protein viewer. Our GUI matches sequences using the Needleman-Wunsch algorithm and then runs iterative Kabsch alignment on alpha carbon positions to ensure good visual overlap on similar regions.

If you have thoughts about other places in Rowan’s GUI where this overlay capability should be accessible, please share your thoughts with contact@rowansci.com!

Macromolecular CIF support

Finally, you can now input and export protein structures using the macromolecular crystallographic information file (mmCIF) format.

Because PDB files can only store up to 99,999 atom records, mmCIF files are a better choice for handling and storing solvated protein systems and very large protein complexes. Additionally, mmCIFs are a newer format and some modern tools no longer support PDB files.

If you’re really in a pinch, you can use https://labs.rowansci.com/protein-editor to convert from mmCIF to PDB or vice versa (though there’s a also very robust converter available here: https://mmcif.pdbj.org/converter/index.php). If you notice any fields that are missing from mmCIF files exported from Rowan, please let us know!

We’re excited to be releasing plane-wave DFT for modeling periodic systems powered by Quantum ESPRESSO! We’re also expanding FEP access to all subscribing academic groups, and we have a few blog posts we’re excited to share (including a new open-source library for efficient molecular data splitting).

Plane-Wave DFT

In 2024, we added periodic simulation capabilities powered by neural network potentials (NNPs), which are often quite accurate and much faster than DFT. So why bother with DFT? Plane-wave DFT is the ground-truth method that NNPs approximate, meaning that it’s useful for generating training data if nothing else. However, we believe that DFT will have continued relevance beyond just dataset creation:

• DFT natively provides electronic structure, which can be used to determine partial charges, band structure, density of states (DOS), Fermi level and band gap, optical and magnetic properties, electron–phonon coupling, and much more.

• DFT should be used to evaluate whether NNPs can accurately model your area of chemical space, and in the case that a system isn’t accurately modeled by extant NNPs, DFT remains a powerful tool.

• Perhaps least importantly, we expect that journals will continue to expect DFT results in supporting information.

Molecular and periodic calculations are very different beasts (see our earlier post on the topic for more), and we want to provide first-class support for both. Quantum ESPRESSO is a leading open-source plane-wave-DFT program, and we’ve begun integrating it into our platform.

Running Quantum ESPRESSO in Rowan

We provide all major DFT functionals and the Standard Solid-State Pseudopotentials (SSSP), a library of curated and benchmarked pseudopotentials covering the first 103 elements of the periodic table. The open-source community has largely centered on these pseudopotentials, and we’ve made them easier to use by automatically loading the suggested plane-wave and density cutoffs (though you can override these yourself). We have also implemented automated selection of plane-wave and density cutoffs based on the SSSP suggested values, along with k-point (the reciprocal space grid points on which the electronic structure is sampled) selection based on cell and the materials density (the user can also manually set all of these values).

For more details on the specifics of modeling with plane-wave DFT, check out our blog post and documentation. When publishing Quantum ESPRESSO calculation, make sure to cite Quantum ESPRESSO, your functional, and the SSSP pseudopotentials that you use. (As with all programs that we host, you can check out our citations page for links.)

To run a Quantum ESPRESSO DFT calculation, you can do so like any other calculation:

• Upload your structure (CIF, xyz, etc.) or draw your structure in our 3D editor

• Optionally, set your cutoffs and k-points

• Select your smearing (very important for metals)

• Choose which tasks you would like to run (e.g. Optimize, Charge, or Energy)

Once submitted, calculations are routed to an A100 GPU running QE 7.3.1 (compiled by NVIDIA). The results are streamed back to the user while running, showing optimization steps, cell parameters, partial charges, and other values.

If we calculate the binding energy of graphite at a bunch of different interlayer distances, we can find the optimal spacing and compare the performance of different methods. Dispersion correction is important to capture the inter-layer binding and pure PBE binds the layers too weakly, predicting a much too large inter-layer spacing. UMA-S-1.2-OMat also vastly underpredicts the binding and overpredicts the spacing, since it is trained on PBE without any dispersion correction.

This initial release of Quantum ESPRESSO only covers basic calculations and scans, but we plan to add workflows to accelerate common materials-science-property predictions, such as modulus, XRD, band structure, density of states, defect-formation energies, and more. To do so, we are joined this summer by Raphael Stone, a 3rd year Materials Science Ph.D. in the ACME Group, and we look forward to a summer of building materials-science-specific workflows with him. If you are interested in learning more about our plans or working with us to develop new materials-science workflows, please reach out.

Academic Group Access to FEP

Several months ago, we announced that Rowan’s FEP workflow was coming out of private beta and was now generally available to subscribing organizations in industry. We’re happy to share that we’re now expanding this access to subscribing academic groups—as of today, all academic groups can run RBFE calculations through Rowan for no extra charge. In the same vein, we’ve also made batch docking accessible to all subscribing Rowan users.

If your academic group is interested in running RBFE (or other workflows), please reach out! Academic group rates start at $250/month and come with full access to all Rowan workflows, as well as easy collaboration and sharing.

Additional Rowan Content

In case you missed, here’s a few highlights from our blog:

• Building on our earlier work on the OpenBind EV-A71 release, Corin did a deep dive investigating how different FEP settings fared on different subsets of the data. Pose selection, simulation length, and local-versus-global FEP settings all make a difference! If you’re interested in applying FEP to real-world problems, check out the post.

• We also released Chalcedon, a fast, memory-efficient Butina-clustering package that makes robust splitting of chemical datasets practical on consumer hardware. Chalcedon is faster and more memory efficient than existing open-source methods by an order of magnitude and is all written in NumPy. For more information, read Eli’s full post on our blog.

• How many hydrogen bonds does this pose form?

• Are there any salt bridges stabilizing this interaction?

• Does my compound fill the pocket?

While we’re proud of our default view (below), we’ve been adding new views to make protein–ligand systems easier to interpret and communicate.

Protein–Ligand Interaction Diagrams

No one wants to count hydrogen bonds by squinting at a ribbon diagram during a meeting (or a hackathon). To make key binding-site interactions easier to communicate, we’re introducing a new protein–ligand interaction diagram view:

This diagram treats the selected ligand as the center of the binding site, then identifies nearby protein residues and classifies their interactions with the ligand.

If you provide a SMILES string, RDKit is used to draw the ligand; otherwise the ligand layout is inferred from the PDB coordinates. This diagram requires explicit hydrogens, since hydrogen-bond detection depends on donor hydrogen positions.

• Hydrogen bonds require a donor–hydrogen–acceptor angle of 120–180°, a donor–acceptor distance of at most 3.5 Å, and a hydrogen–acceptor distance of at most 2.7 Å.

• Polar contacts are defined as close contacts between polar heavy atoms (N, O, or S) that are not classified as hydrogen bonds.

• Salt bridges are detected between charged ligand atoms and nearby charged residues.

• Hydrophobic contacts are close contacts between neutral carbon-like ligand atoms (C or S) and hydrophobic side-chain atoms.

• Generic van der Waals contacts are shown with gray residue labels: close heavy-atom contacts that are not classified as hydrogen bonds, salt bridges, polar contacts, or hydrophobic contacts.

• Ligand surface outlines help show which parts of the ligand are protein-facing versus solvent-exposed. They are calculated from all the contacts above plus additional nearby residues within 5 Å (up to 100 residues).

This view—like our other views—updates as you switch between poses. The residue labels can be rearranged by clicking and dragging, and the view can be customized further using the settings menu (accessible via the gear icon).

Want to visualize your existing structure? Bring your own file and just use the view: https://labs.rowansci.com/interaction-diagram.

Protein Blob Surface

Another view we’ve received a lot of requests for is a “blob” protein surface view with electrostatic coloring. Different tools generate these surfaces differently, but the general idea is to represent the protein’s volume while highlighting electrostatic character. This makes it a bit more obvious to see how a ligand sits within a pocket, and can be useful for brainstorming e.g. directions where additional atoms could be added.

Positive electrostatic potential is shown in blue, while negative electrostatic potential is shown in red.

To make the creation of these views tractable in the browser, we use some heuristics. Atom charges come from the structure when available; otherwise we estimate them from residue and atom names. Similarly, the surface generated is a vdW-like Gaussian surface, not a true solvent-excluded surface.

This view can be accessed via the gear icon in the protein viewer.

Space-Filling Molecules

We’ve also received requests for a space-filling mode for visualizing molecular structures!

This view can be accessed via the gear icon in the molecule viewer.

If there are views that would be helpful for your research and communications, please let us know at contact@rowansci.com! While we think simulations are cool and fun, clean visualizations matter too. We want Rowan to help bridge the gap between powerful modeling methods and their real-world scientific impact.

Eagle-eyed users of Rowan may have noticed some changes in our logfiles, and Substack readers may have noted a decrease in the number of new features that we’ve shipped recently. We have been in the process of switching our workflow-running backend from a single monolithic package to an amalgamation of library- and workflow-specific packages. We recently shipped updated versions of over half of our workflows, with the rest soon to follow.

This post explains why we’re doing this: the technical problems we’ve encountered in scaling Rowan, the various solutions we considered, and the approach we’ve ultimately settled on. This is a longer and more engineering-focused post than most of our writing, but we hope it will be useful to anyone who is interested in building complicated systems, whether virtual or physical.

The problem

When we started building Rowan’s workflow backend, things were simple. We only had a few packages and we shared functionality between workflows to reduce the size of our codebase, ease maintainability, and increase developer velocity. We utilized modern development methods such as Ruff for formatting and linting, mypy for type checking, and Pixi for package management, ensuring that we had fast and reproducible builds. Any time we needed a new package we would add it, and over the past two years our codebase has grown significantly.

This growth came at a cost. Computational chemistry is a varied field requiring niche chemistry, physics, and math expertise to develop highly performant code. This code is often written by grad students with little software development expertise and no funding to perform continued maintenance. This has lead to an incredibly fragmented ecosystem with many orphaned packages being pinned to outdated dependencies, promiscuously importing numerous packages for minor tasks, or not fixing major bugs that have been open for many years.

As we added packages (currently 151 direct dependencies and innumerable indirect dependencies), solving for an acceptable combination of packages and their dependencies became incredibly difficult. Conflicting PyTorch and CUDA versions in packages are a nightmare to deal with; some packages only support up to Python 3.12 (despite the end of full support for Python 3.12 happening over a year ago) and some packages are arbitrarily hard pinned to specific versions of packages. Updating or adding new dependencies can upset the careful balance, causing certain packages to accidentally regress, or preventing the solution entirely. This lead us to purposefully avoid adding certain features (e.g. certain NNPs, periodic DFT, transition state search packages, etc.) due to the complexity that they introduced.

The monolithic architecture of our codebase also came at a cost, as it encouraged a tangled web of imports between parts of the code that:

• slowed startup times, as the entire codebase is traversed following imports (even the anticipated explicit lazy imports in Python 3.15 are not a complete solution),

• made it difficult for mypy to type check everything due to the codebase’s size and complexity (taking a minute on a fresh clone of our repo), and

• complicated refactors, as developers (or their agents) had to be careful to follow every import to ensure that changes didn’t break things.

So far, we have been able manage some of this package complexity by outsourcing GPU-related complexity to images on Modal. This avoided developers needing to have CUDA-capable laptops, and allowed different GPU-related dependencies for each Modal image that was deployed. However, it was difficult to maintain consistent images, as the snarl of imports from our monolithic codebase ended up importing everything into our Modal images. Additionally, we no longer had fully atomic deployments and couldn’t use uv.lock files to ensure the Modal images didn’t drift, preventing rollback if something went wrong. The dependency on Modal to help out our mess also made it difficult to deploy our platform to our customer’s private clouds.

Potential solutions

All of this was slowing down our development velocity. There were many potential solutions: a partial refactor, excising of problematic dependencies, or leaning more heavily into microservices for new features. However, none of these options provided the necessary base for future growth, particularly if we want to be able to:

• Ship fast

• Have atomic deployments

• Support a wide range of features

• Not rewrite everything ourselves

We have performed many partial refactors throughout the growth of our codebase (developers should always be reforming), but partial rewrites cannot deal with the fundamental problem of a monolithic codebase nor the fact that we have to deal with fundamentally conflicting packages. We’ve also often excised dependencies (occasionally rewriting them internally) to simplify our dependency graph, but attempting to rewrite all packages that cause us problems is a great way to introduce bugs and never get anything done.

Many companies solve this problem via microservices where each fundamental operation becomes its own server (typically through containerization) and a single end-to-end workflow calls many of these microservices in an organized manner. This fundamentally solves the dependency issue, since each microservice just has to expose a REST API and can use whatever dependencies it wants under the hood. There are a variety of computational chemistry projects that use this as a solution, including FireWorks, atomate2, and AiiDA.

We disliked this for several reasons, however. Many Rowan workflows combine a cascade of scientific functionality: protein–ligand co-folding can utilize conformer search, geometry optimization, co-folding model inference, pose deduplication, PoseBusters scoring, and strain calculations all run in sequence. Splitting this entire workflow across network boundaries dramatically increases the complexity and fragility of the workflow by introducing a bunch of new potential failure modes.

Basically, we wanted to be able to isolate dependencies by workflows without having to completely fragment our runtime deployment.

Our approach

We decided to perform a complete rewrite of our scientific backend. This is not something we took lightly; rebuilding takes significant amounts of time and can often fall afoul of the second system effect. However, when done correctly it can accelerate future developer velocity and cut many of the Gordian knots that existed in the prior system that were intractable via traditional refactors.

We architected our new package (called Condor) into multiple distinct layers: core, libraries, and workflows, all in the same monorepo with their own lockfiles. In both the libraries and workflows there are numerous distinct packages, each focused on performing a singular task. Imports between libraries are discouraged to prevent complicated webs from forming. Judicious application of factory-based lazy loading of modules with local imports further helps to segregate modules and provide a consistent interface while limiting the number of packages loaded in each workflow.

Core contains our fundamental datatypes and algorithms. It provides numerous abstract base classes (e.g. for quantum-chemistry engines) that get concrete implementations in other packages (e.g. the psi4_engine library). It is available to all libraries and workflows, and as such contains a minimal number of dependencies (e.g. numpy, polars, more-itertools, stjames).

Condor’s internal libraries are where most of the work happens. Each one is dedicated to a single conceptual task and imports from core. There are internal libraries for interfacing with every quantum-chemistry code that we use (e.g. Psi4, xTB, GPU4PySCF), every conformer generator (e.g. RDKit, openconf, CREST), and every optimizer (e.g. geomeTRIC and Sella). Separate packaging simplifies testing and development, while also helping to restrict cross-cutting imports that lead to numerous transitive dependencies. It is now obvious if an import happens between libraries and is significantly easier to limit to situations where it is strictly beneficial (e.g. our PySCF and GPU4PySCF engines are distinct packages to isolate the base PySCF from GPU-related dependencies, but the GPU4PySCF engine reuses much of the PySCF engine code).

Workflows are the interface to the wider world. They translate the logic in our StJames workflows to a form that Condor can understand. They manage the conversion of settings, the setup of saving callbacks, and the management of the tasks queue. Workflow packages in Condor aren’t intended to contain significant scientific logic; instead, they orchestrate the running of libraries and present a consistent API to the outside world. This allows us to refactor internally while maintaining a consistent interface for our users.

Each package has its own set of tests. Tests related to a commit’s changes are run on the package containing the changes and all downstream packages. Since they are independent packages, the tests can all run independently, allowing for massively parallel testing and accelerating developer velocity and bug fixing. On pushes to our master branch we sometimes have 50 independent GitHub Actions workflows running. The vast majority of them complete in a couple of minutes, keeping our bills down, and the strict partitioning of our code helps us worry less about integration problems (though we do have many integration and regression tests).

Now that each workflow is independent of the packages needed in other workflows, we can quickly ship updates and new workflows that would previously have caused conflicts. Since all of our code is in a monorepo, we don’t have to worry about conflicting internal versions and can have atomic updates every time we deploy (which is often multiple times per week). Should a change ever need to be rolled back, we can do so nearly instantly, as we have a full snapshot of the exact state of our system thanks to the lockfiles.

How we implemented it

This was a significant undertaking, and one we debated for a long time, but something we ultimately decided was necessary in order to maintain high-quality, performant software. We separated the work into three stages: ideating and investigating, scaffolding and automating, and implementation and testing.

First, we spent a couple of months thinking about the problems with our existing architecture and code and playing around with toy versions of the new architecture to test ideas. We were under no pressure to ship a new backend, and this allowed ideas to percolate and for us to play around with setups without committing to anything. There is a dearth of examples of how to set up large projects for the smaller-than-Google but bigger-than-single-package scale. We aren’t big enough to truly benefit from most build systems like Pants and Bazel, and they come at a heavy cost to developer speed. The initial stage of planning convinced us that modern environment- and package-managers like uv and Pixi along with a judicious use of GitHub Actions can be used effectively in place of a dedicated build system. This initial investigation phase convinced us of the need for a major rewrite and that it would be possible to do so in a straightforward manner.

Second, we threw out all of the previous toy code and started from scratch. We scaffolded a framework, wrote automation scripts, and developed high-quality agent skills. We hand-wrote much of the core code to ensure that future development would be fast, correct, and consistent. We set up numerous scripts for automating package setup, tests, and deployment so that we could maximize consistency (and thus decrease the mental load on developers). We spent large amounts of time writing numerous examples of good docstrings, good code hygiene, and what not to do, so that developers and agents would know how to write code when the time came.

Third, we all pitched in and ported code. In classic software-development style, developers were assigned workflows based on their expertise, and shepherded them through the development, testing, and deployment phases. Coding agents helped with porting the code quickly, but developers were still responsible for making sure the code was correct and in line with Condor’s paradigm. Multiple developers were assigned to review and test each new workflow. In doing so we caught many bugs, some of which were latent in the previous code, and significantly improved the quality of code. We committed to minimizing the scientific changes between the codebases, only doing so where clear improvement could easily be achieved, or where there was an obvious bug. This helped prevent work from spiraling out of control, as there are always ways that code can be improved. Through this process we were confident that we were shipping code that was better than before, and that it will serve as an excellent base for building in the years to come.

Updates

During this process we took the liberty of updating many parts of our codebase.

We’ve updated our developer toolset to accelerate development and improve correctness. We now use ty for type checking and do so at the package level, taking a few seconds at most. We use rumdl for formatting our markdown consistently. We use prek for managing pre-commit hooks, using nested prek.toml files in each package so that our lints and type checking run quickly on every commit (our hooks only take a few seconds thanks to the speed of Ruff, ty, and rumdl). Packages are managed by either uv or Pixi depending on the need for conda-forge packages (uv is preferred but sadly doesn’t yet support conda packages).

We’ve improved our test coverage and made more logical tests. Not everything needs to be tested at the highest level of theory; g-xTB gradients are just as good as DFT gradients when testing our optimizer code, while significantly less costly. The logical separation into packages allows us to more easily mock out parts that are irrelevant to the tests (e.g. the conformer search workflow can have its conformer generation code replaced by a pre-existing ensemble in tests of the clustering and pruning steps). While mocking code is traditionally difficult to write, agentic coding makes this easy.

Tests are marked with how long they are expected to take (seconds, minutes, hours), allowing us to quickly run a subset of tests to gain a quick understanding if anything broke, and then run longer running tests before merging to master. We’ve even compiled macOS binaries of many executables that were Linux only. These are automatically swapped out at runtime on the machines of our Mac developers so that they can run our test suite locally instead of having to rely on Docker images or our CI/CD pipeline to test.

We have rewritten how we perform optimizations. The TRIC coordinate system is now used for much larger non-periodic systems than before (previously we switched to Cartesian for all fast methods). Though each step is a bit slower than Cartesian due to the need to perform coordinate transformations, the quality of each step is much better. This allows for faster overall optimizations due to the optimizations taking fewer, better steps, along with faster loading of results for our users. We now batch database-save callbacks during optimizations to avoid hammering our database with multiple step saves every second and use futures to perform the saves, preventing database communication from slowing down optimizations while still allowing users to follow the progress of their calculations.

We’ve updated GPU4PySCF to the latest version, providing significant improvements. The new JoltQC library in GPU4PySCF provides JIT-compiled kernels that normally take several minutes for every new calculation, so we warm up the kernels at image-build time, providing faster starts for our users’ jobs instead of the multi-minute JIT compile times needed previously. If the Modal GPU image is cold, startup should now be <30 seconds, and <1 second if the image is warm.

We’ve improved our logfiles, providing cleaner, more relevant information. Logfiles are a great way to gain a greater understanding of what is happening during a calculation and ensure that things are running as expected. Not all information is saved to our backend in a structured manner, but we think it is important to give users access to data that can be useful for debugging calculations. Our updated logfiles now display more data in an organized manner. We better suppress the spurious output of many of our dependencies, and surface more relevant information for the user. We’ve even added resource tracking to the logfiles for some workflows, allowing for a better understanding of what resources were needed to run a given calculation and how close you are to the resource limits on a machine.

We are improving our security and portability by integrating more tightly with AWS. We are switching our application-layer hosting from Digital Ocean to AWS, keeping communication between our application layer, scientific workflow layer, and database all within our AWS VPC. This will make it much easier to deploy our platform on our customers’ virtual private cloud instances, decreasing the engineering lift required to do so.

We’ve added better recovery from errors. Random segfault sometimes occur in programs like CREST for no apparent reason, and the executable is now automatically restarted when a segfault is detected. For issues like out-of-memory errors that can happen in large DFT calculations, we now handle them more gracefully, properly shutting down the image with a useful error message. (If you need to run very large DFT calculations on our infrastructure, please contact us for some tips and possibilities.)

Lastly, we’ve updated our units to the latest CODATA 2022 SI values. This should have minimal impact on calculations, with the biggest change being in the eV to Hartree conversion value. If you are comparing absolute values of calculations for AIMNet2, OMol25’s eSEN conserving small, or UMA models, you can multiply old energy values by 1.00000050545 to match the new values (this is important if you calculated your reactants and transition states at separate times).

As we transition our workflow backend, you may experience some bugs (though we hope to keep these to a minimum). If you notice anything is wrong, doesn’t work as expected, or could be improved, please let us know. You can report bugs by clicking on the bug icon in the top right corner of the screen. This will pop up a box where you can enter the issue you are seeing, and optionally share the calculation privately with us (we are unable to view your calculations unless you explicitly share them with us due to security considerations).

To write a good bug report, summarize the problem you are having in a single sentence in the subject line and then write a more detailed description about what you are attempting to do, the result you are seeing, and the result you expect to see in the description section. E.g.

Subject: Scan points not loading during run

I submitted a scan over the C–C–C–C dihedral angle in butane, but no points are displaying until the entire scan has completed. I expect to see individual scan points populate as they complete.

Well-written bug reports help us to quickly diagnose and fix problems (occasionally even the same day), and are very helpful as we continue to grow our platform.

We plan to add many new features and updates, and are looking forward to a summer of building new features and workflows. We will be joined by four interns this summer to work on everything from periodic DFT, to educational materials, to MD, to conformer search. If there are workflows or features that you would find useful, please let us know.

Today we’re launching a significantly improved version of our analogue-docking workflow, a new pocket-detection workflow, and the new g-xTB method with support for analytical gradients.

Analogue Docking

Analogue docking allows users to quickly dock a series of related ligands against a protein: instead of docking each ligand separately against the pocket, analogue docking uses a user-provided template to generate ligand conformations, yielding well-aligned poses.

While our earlier analogue-docking workflow worked well in many cases, we struggled to robustly generate well-aligned poses for non-trivial modifications or complex scaffolds. Our new analogue-docking release performs significantly better for real-world RBFE datasets, approaching the performance of manual pose alignment without requiring any external chemical intuition. This means that downstream FEP runs are better converged, complete faster, and produce more accurate results, helping us get closer to our goal of fully automated end-to-end RBFE workflows at scale.

What We Changed

Rowan’s analogue-docking workflow begins by identifying the maximum common substructure (MCS) between the template pose and the new ligands. The MCS is then used to constrain the new ligand’s pose, ensuring good alignment between the two structures. In our previous MCS implementation, differences in stereochemical annotations or Kekulization confused the MCS finder, preventing the workflow from finding chemically reasonable poses. We’ve fixed this and added fallback logic to ensure we find a reasonable MCS even in confusing situations.

We’ve also substantially improved the logic used to generate new pose conformations. The previous implement relied exclusively on RDKit’s ConstrainedEmbed() function, which often struggled to generate diverse conformer ensembles given heavily constrained molecules. We’ve added a post-embedding torsional-Monte-Carlo conformer search step powered by openconf, which dramatically expands the number of poses generated.

Benchmarking Known Pose Retrieval

We benchmarked these improvements against the “JACS” RBFE test systems from Wang et al. 2015, each of which comprises a set of nicely aligned ligands bound to a protein target. For each system, we chose a single ligand as a template, input the remaining ligands in SMILES form, and ran analogue docking. The changes to analogue docking led to significantly improved overlap for all ligands versus our old analogue docking workflow.

Here’s the result of the old analogue-docking workflow, with messy pose alignment and generally poor overlay:

Here’s the result of the new analogue-docking workflow, with nearly perfect overlay and lower RMSD & docking scores.

We assessed the overall quality of the ensemble by comparing the heavy-atom RMSD of the best-aligned pose for each analogue to the pose reported in the JACS benchmark set. Across the board, the new analogue-docking workflow generates a significantly better match to the reported hand-aligned structures. The old algorithm sometimes found entirely different binding modes (RMSD >2 Å). The new approach nearly eliminates this, with poses almost always within 1 Å RMSD.

Benchmarking Downstream RBFE

Finally, we used all three sets of poses as inputs to RBFE calculations and compared the performance of the resultant runs. For the analogue-docked structures, we used the outputted pose with the best docking score. While the poses generated by the old analogue-docking workflow (”Old”) often produced results that were dramatically worse than results generated with the reported poses (”JACS”), the new analogue-docked poses (”New”) generally approached or even exceeded the accuracy of the reported poses. Additionally, the new poses often resulted in much faster RBFE runtimes than the old structures (e.g. the BACE and Thrombin sets).

Here’s the full table of our results. The highest-performing results in each category within a row are bolded.

(A few details: the "Old" results for the "Thrombin" set include only 10 ligands instead of 11 because one pose was so poorly aligned that the RBFE workflow could not calculate a ΔG for that structure, and all MCL1 results are missing one troublesome ligand that defied both “Old” and “New” analogue-docking protocols.)

Here are a few of the more striking comparisons:

Analogue docking remains available to all Rowan users.

Pocket Detection

If you’re starting a project with a new protein target and don’t yet have a bound crystal structure, one of the first challenges is figuring out where compounds should bind. Traditionally, this means inspecting the protein by hand: looking at the surface shape, electrostatic potential maps, or hoping that someone has already reported observed binding sites in the literature. That approach can work well, but it often depends on strong prior hypotheses, existing structural data, and a fair amount of manual effort.

Another option is blind docking: letting the docking software search the entire protein surface for binding regions automatically. This can generate pocket hypotheses when little is known about a target, but it’s a blunt instrument: docking software wasn’t designed for pocket detection, so the results are noisy and still require manual curation.

Rowan now includes a pocket-detection workflow that identifies potential binding pockets using a purpose-built geometric algorithm. Our workflow uses Pocketeer, a code from Charlie Harris that builds on ideas from fpocket. Pocketeer analyzes the geometry of a protein structure by placing spheres around the protein surface, determining which regions are sufficiently buried, clustering those regions into candidate pockets, and scoring each pocket using geometric and volumetric features.

To run a pocket-detection workflow, simply upload a protein structure or add one using its PDB code, perform any preparation steps (removing waters, rebuilding unresolved residues, and so on), and hit “Submit.”

The workflow runs in seconds. Detected pockets can be visualized directly in Rowan and quickly resubmitted into docking or batch docking workflows.

g-xTB with Analytic Gradients

g-xTB is a semiempirical tight-binding method derived from density-functional theory (DFT). Thanks to physics-informed approximations, such as range-separated approximate Fock exchange, g-xTB is orders of magnitude faster than DFT while having an accuracy similar to range-separated hybrid DFT with a triple-ζ basis set (check out our blog “The ‘Charlotte’s Web’ of Density-Functional Theory (DFT)“ for a deeper explanation of range-separation). Unlike neural network potentials, g-xTB does not require large amounts of fitting data and thus generalizes well across the periodic table, spin multiplicities, weird geometries, and domains of chemistry.

We already use the preliminary release of g-xTB in our bond-dissociation energy and pKa workflows, but the addition of analytic gradients opens up new possibilities in geometry optimization and property prediction like IR. Analytic gradients make it simple to run transition-state optimizations, such as this 95-atom hydrocupration reaction.

There will be slight deviations in the energies between the old and new versions; the updated version is slightly more accurate. Direct comparisons between results using different versions should be avoided, but g-xTB is fast enough that any calculations can easily be re-run.

We’re releasing a new microscopic pKa–prediction method today at Rowan, as well as—for the first time—a logo and a major refresh of our website.

Rowan pKa (g-xTB)

pKa prediction has a special place in our heart. Microscopic pKa was the first workflow we launched, over two years ago, and we’ve kept thinking about pKa since then—we’ve released a machine-learning-based macroscopic pKa workflow, wrote a blog post about microscopic and macroscopic pKa, studied pH-dependent aqueous solubility, and seen users apply our original pKa workflow to lots of interesting scientific problems.

Our original microscopic pKa workflow used ETDKG conformers and AIMNet2/CPCM-X(water) energies to compute ∆G for an acid–base pair and then applied a quadratic free-energy relationship to convert ∆G into a predicted aqueous pKa value. While we’ve been happy with this workflow, we’ve also noticed some issues over time:

• AIMNet2 doesn’t work for the whole periodic table, meaning that some molecules are totally impossible to study with Rowan pKa (e.g. anything with metals or exotic elements).

• While AIMNet2 was state-of-the-art in early 2024, when we were creating v1 of Rowan pKa, it’s now far from the most accurate low-cost method that exists, particularly for tricky thermochemistry like conjugate acid/conjugate base pairs.

• And the conformer-generation pipeline that we used in Rowan pKa struggles with conformationally complex molecules, often running slowly or missing important conformers.

We’ve been looking forward to addressing these issues for some time, and today we’re releasing an updated version of Rowan pKa that (we think) represents a significant improvement in accuracy, generality, and reliability.

How It Works

Rowan’s new pKa-prediction method is powered by g-xTB, the new semiempirical method developed by Stefan Grimme and co-workers. g-xTB performs well on thermochemical benchmarks and contains an adaptive charge-dependent basis, making it a good choice for handling conjugate acid/conjugate base pairs. As with our recent solvent-dependent conformers workflow, we combine g-xTB single-point energies with CPCM-X(water) solvent corrections and GFN2-xTB vibrational free-energy corrections from single-point Hessian calculations to get a final per-compound free energy.

As with our earlier AIMNet2-based method, we use ETKDG to generate conformer ensembles; however, we now use the ReSCoSS-style clustering and filtering from our solvent-dependent conformer-search workflow (detailed here) to generate diverse conformer ensembles more efficiently. We’re also now optimizing in implicit solvent, which makes geometries more physical and should attenuate unphysical intramolecular interactions. (We plan to investigate additional conformer-generation methods here in the future, as we think there are probably more efficient ways to generate conformers for pKa than ETKDG.)

Once we’ve computed ∆G for the acid–base pair, we must still convert this to an aqueous pKa value. Previously, we used a quadratic free-energy relationship with per-element and per-valence corrections to improve performance; in the new g-xTB-based method, we’ve instead switched to per–functional group linear free-energy relationships. The scaling factors were obtained by fitting to a subset of the Dwar-iBond dataset, and new functional groups were automatically added based on the Bayesian information criterion.

This new method, like our previous AIMNet2-based method (and unlike our Starling ML model), falls under the “Quantum Mechanics” family of pKa-prediction methods; it relies mainly on inference-time simulation to capture complex chemical behavior, and uses only simple linear scaling to convert from simulated values to experimental data. This makes the method relatively robust and able to handle exotic chemistry or complex systems, but also means that it will be slower and less accurate than Starling for fast inference on drug-like molecules. (If you want to run millions of pKa values to sanitize input SMILES strings, this isn’t the right method for you.)

Benchmarks

We reinvestigated the original AIMNet2-based pKa-benchmark systems to see how our new method fared in comparison. (These benchmarks were run only once, after method development was entirely finished, and not used to fine-tune any scaling factors.)

In general, we found that our new g-xTB pKa method outperformed the original AIMNet2-based method. On the Rombouts set of tricyclic amidine BACE1 inhibitors, for instance, g-xTB shrinks the MAE from 1.06 to 0.59 pKa units:

Similarly, we see modest improvements on the Miller–Doukas–Seydel folate-inhibitor dataset (shown below, top) and the Müller dataset examining the effect of α- and β- substituents like oxetanes on cyclic amine basicity (shown below, bottom).

The new pKa-prediction method is also able to handle organometallic systems, which can be helpful:

While we don’t expect to have solved all pKa-related issues with this update, we’re excited to release a new and improved version of this popular workflow. Please let us know if you have any issues and we’ll do our best to fix them in the future!

To run the new g-xTB-based microscopic pKa workflow, simply select “Rowan pKa (Wagen 2026)” from the method dropdown on the microscopic pKa workflow. As with the other pKa-prediction methods here, this is available for all users (paying and otherwise).

Logo and Website Refresh

Since launch, we’ve been using “🌳 Rowan” as a placeholder for a logo that would one day come. Today, we’re excited to introduce our new logo alongside a major refresh of our website.

The logo draws on the five-pointed symmetry of Rowan flowers and the charmingly lo-fi aesthetic of old-school orbital density plots.

The updated site features fully redesigned landing pages tailored to key Rowan use cases, including medicinal chemistry, structure-based drug design, materials science, and agentic science.

We’ve also expanded our website’s social proof sections to highlight teams using Rowan in production, including ArrePath, Orogen Therapeutics, and Syntara. We’re grateful for the opportunity to support their work. As Kurt Thorn, CTO of ArrePath, shared:

ArrePath uses Rowan as its quantum chemistry backend for Ariadne, our custom medicinal chemistry co-pilot AI. Rowan works alongside our internal ML tools as an integral part of our AI/ML drug discovery platform. It’s a great tool for computing compound pKas, structures, and other molecular properties, and helps drive real-world compound prioritization and decision making.

If you’re looking for computational tools that are ready to plug into your molecular R&D workflows and agents, we’d love to connect.

Happy Eastertide! This week, we’re happy to share a diverse litany of enhancements to Rowan: new API features, improvements to our tautomer and descriptor workflows, and an optional new billing scheme for subscribers.

New Python API Features

Webhooks

You can now configure webhook endpoints via Rowan’s API to be notified when workflows complete. This allows your Rowan-powered applications to react automatically to finished jobs—triggering downstream analysis, syncing results into internal systems, or updating users in real time without polling the API.

To use webhooks through Rowan, first create a webhook secret:

import rowan

secret = rowan.create_webhook_secret()

(This command is idempotent—if a secret already exists, it will be returned.)

Then simply supply webhook_url to any workflow submit function:

workflow = rowan.submit_admet_workflow(
	initial_smiles="O=S2(=O)OC(c1ccccc12)(c3cc(c(O)cc3C)C(C)C)c4cc(c(O)cc4C)C(C)C",
	name="test ADMET (webhook)",
	webhook_url="<https://your-server.com/webhook>",
)

print(f"Submitted: <https://labs.rowansci.com/workflow/{workflow.uuid}>")

When the workflow completes, Rowan will POST the result to webhook_url with an X-Rowan-Signature header. You can securely verify the result on your server using HMAC-SHA256 with:

rowan.verify_webhook_secret(raw_body, signature_header, secret)

As usual, refer to our Python API documentation if you have any questions.

Draft Workflows and Dispatch Information

You can now submit “draft” workflows through Rowan’s API—simply add the argument is_draft=True to any workflow submit function.

workflow = rowan.submit_admet_workflow(
	initial_smiles="O=S2(=O)OC(c1ccccc12)(c3cc(c(O)cc3C)C(C)C)c4cc(c(O)cc4C)C(C)C",
	name="test ADMET (webhook)",
	is_draft=True,
)

You can then call workflow.dispatch_info() to retrieve information about how long the workflow is predicted to take to run and what hardware it will run on. Here, we can see that the above workflow won’t need to be dispatched to special hardware, will run on CPU, and is estimated to take only 0.15 minutes to run:

print(workflow.dispatch_info())
#DispatchInfo(to_be_dispatched=False, compute_hardware='CPU', estimated_runtime_minutes=0.15)

The draft workflow can then be submitted with workflow.submit_draft() or deleted with workflow.delete().

Tautomers in Non-Aqueous Solvents

We’ve had requests to compute tautomer ratios in non-aqueous solvents for some time now, and we’ve finally made this possible! You can now customize the multi-stage optimization settings to change how tautomers are scored, including changing the final solvent employed.

This allows for investigation of solvent effects on tautomer ratios, which can be pretty dramatic—for instance, dimedone favors the diketone form by 3.1 kcal/mol in chloroform (shown below), but the gap shrinks to 1.1 kcal/mol in DMSO.

New Descriptors (COSMO, Volume, Flexibility)

We’ve added a set of COSMO-based descriptors to Rowan’s descriptors workflow. COSMO calculations are run through xTB and provide a suite of output properties, which allow for automatic detection of e.g. total polar surface area at the GFN2-xTB/COSMO level of theory. (The solvent can be selected upon submission.)

Here’s what this looks like for a sample organometallic complex:

We’ve also added molecular_volume and flexibility_index descriptors, as requested by users. (The flexibility is calculated following the Kier φ formula.)

Overages

Our standard subscription tiers include weekly credit allocations that work well for many users, but we’ve heard from teams with variable computational needs that more flexibility would be nice—it’s frustrating to constantly have to estimate how many credits a round of calculations will cost and track usage relative to your account’s weekly limit.

We’re excited to introduce overage billing logic to Rowan today. With overages enabled, your calculations run without interruption and you’re billed only for what you use at the end of each month (at our standard rate of $0.04/credit).

We pay plenty of usage-based subscriptions here at Rowan and we don’t want to surprise anyone with unexpected bills. To keep costs within limits, you can set configurable credit limits at both the organization and individual level so you’re always in control. We also provide analytics to track spend by workflow type and by user at labs.rowansci.com/account/credits, so you should never have to wonder where credits are going.

Since this feature is new, we’re not yet allowing users to turn on overage billing themselves—if you’re interested in enabling overages for your account/team, let us know and we’ll get you set up!

Other News:

• We released a blog post yesterday comparing the “fast” and “recommended” settings for Rowan FEP. On the MCL1 benchmark set, using the “fast” settings makes the RBFE 4x faster with minimal loss in ranking accuracy, although the predicted energies are worse. If you’re interested in compound prioritization, consider using “fast” settings in your FEP runs—it might work well for your system!

• We also recently released a preprint on transition-state searching! In collaboration with Jonah Marks and Joe Gomes from the University of Iowa, Jonathon Vandezande (Rowan’s director of computational chemistry) found that the ML-FSM algorithm can be combined with NNPs like UMA and OMol25-eSEN-sm-cons to quickly find transition states in a fully automated fashion. This is how Rowan’s double-ended transition-state search workflow runs—while we’ve been happy with the performance anecdotally, now we have data to show how well it works!

• While this isn’t strictly first-party Rowan content, Jonathon also just published a guide to using AI coding tools like Claude Code and Codex. If you’re interested in using these tools but haven’t yet, or if you’re wondering what the Rowan tech stack looks like these days, check out his post.

• Finally, we’re excited to welcome Zach Fried to the Rowan team. Zach defended his PhD from MIT last month, where he studied experimental and theoretical methods for detection of interstellar molecules. While we don’t plan to get into the interstellar molecular detection field just yet at Rowan, we’re excited to put Zach’s formidable skillset to use. Welcome!

When we started Rowan, we thought that the web-based interface would be how most users interacted with our workflows—and, to date, we’ve been right about this. Rowan’s interface makes it simple to submit calculations and understand the results, which (we think) makes it possible for scientists who aren’t simulation experts to gain insight from our tools. We’ve never wanted Rowan to be a tool just for experts, which is why we’re happy that every semester we get used for undergraduate classes around the globe.

In the 2.5 years since we’ve started, though, a lot has changed. The rise of AI coding tools like Claude Code and Codex has meant that more and more people who don’t identify as professional programmers are building their own scripts and applications: we now regularly talk to lab scientists who are writing their own sophisticated software to automate various tasks. Even for experienced software developers, AI compatibility is critical (as Patrick McKenzie has noted), and we’ve known for months that Rowan’s API is not nearly as mature as it needs to be to integrate nicely with these tools.

In parallel to this, we’ve become quite optimistic about the potential of “AI scientists,” or agentic AI systems, to drive scientific progress. There are considerable advantages to combining LLMs with deterministic simulation-based tools: LLMs can handle unstructured or semi-structured data and troubleshoot simulation errors, all of which are tough for conventional simulation tools, while using benchmarked simulation-based tools makes the AI’s proposals verifiable and auditable (and, we expect, will help to prevent hallucination).

Users of Rowan’s Python API will know that things have been a little difficult to use to date; the functionality is “minimal,” to quote one early user. Today, we’re releasing a major update (v3.0.0) to rowan-python, which makes it significantly easier to build atop Rowan’s API. We now see our API as the second interface to Rowan—coequal in scientific and product importance to our web interface—and we’re committed to making it as easy as possible to use Rowan solely via code.

While committed developers (or LLMs) can skip straight to the repository or the updated API docs, here’s our summary of the big changes.

Typed Outputs

In previous versions of Rowan’s API, we returned workflow data as a giant Python dictionary. This made it tough to easily retrieve and use workflow data: users had to manually navigate and decrypt our internal data-storage format for every workflow. We heard from a lot of users that this was frustrating and made building with Rowan difficult (and we experienced it ourself).

In the new version of Rowan’s API, all workflows now return a dataclass with easy-to-understand properties that match what’s shown through the web interface. This makes it easier to understand what’s going on when and simplifies downstream integrations. Each workflow type has its own result class (ConformerSearchResult, pKaResult, DockingResult, &c), with properties and methods specific to that workflow.

Result objects are typed and have helpful docstrings, making it easier to figure out what’s going on. IDEs will autocomplete available properties and typing help(result), hovering in VSCode, or result? in IPython will show you exactly what’s available. This also makes it easier for AI agents to use Rowan by minimizing the need for large external documentation blocks that fill up context windows. (Tough luck for nvim users like Corin, though.)1

Here’s what this looks like in practice:

Old Return

workflow.wait_for_result()
print(workflow.data)
# {'uuid': 'abc123', 'calculations': [{'uuid': 'def456', 'molecule': {'atomic_numbers': [6, 6, 8, ...], 'positions': [[0.0, 0.0, 0.0], ...], 'energy': -2931.662913, 'charges': [0.12,
-0.34, ...], 'multiplicity': 1, 'charge': 0, ...}, 'method': 'aimnet2_wb97md3', 'tasks': ['optimize'], ...}], 'status': 'completed_ok', ...}

energy = workflow.data["calculations"][-1]["molecule"]["energy"]
charges = workflow.data["calculations"][-1]["molecule"]["charges"]

New Return

result = workflow.result()
print(result)
# <MultiStageOptResult energy=-2931.662913 H>

energy = result.energy
charges = result.charges

Pythonic Workflow API

We’ve also improved how workflow objects are structured in rowan-python. As before, every workflow has a dedicated submit() function that allows users to tune the input options (matching the “Submit” page on the web interface). These functions return a Workflow object, which now has a variety of useful methods following the concurrent.futures.Future pattern.

• fetch_latest() loads data from the database and returns an updated Workflow (or updates the current object in-place).

• update() allows users to modify workflows: renaming, sharing, moving folders, email notifications, and so on. stop() allows users to stop running workflows, while delete() allows users to delete them.

• done() checks if the workflow is done.

• result() returns the workflow’s result object—if the workflow is not finished, the method will by default wait until the result is ready, checking every 5 seconds, although this can be tuned.

• stream_result() polls the workflow and returns partial results until the final result is ready.

The recommended default pattern is now workflow.result(), which waits for the workflow to finish and returns the aforementioned typed result object. This replaces the old verbose wait_for_result().fetch_latest(in_place=True) pattern.

These new methods make it simple to write scripts that used to be complicated. For instance, here’s a calculation that runs an optimization and updates the user every few seconds on the optimization’s progress:

from stjames import Method, Molecule

import rowan

rowan.api_key = "rowan-sk-your-key-here"

big_smiles = "CC1=C2[C@H](C(=O)[C@@]3([C@@H](C[C@@H]4[C@](C3[C@@H]([C@@](C2(C)C)(C[C@@H]1OC(=O)[C@@H]([C@H](C5=CC=CC=C5)NC(=O)C6=CC=CC=C6)O)O)OC(=O)C7=CC=CC=C7)(CO4)OC(=O)C)O)C)OC(=O)C"

workflow = rowan.submit_basic_calculation_workflow(
    initial_molecule=Molecule.from_smiles(big_smiles),
    method=Method.AIMNET2_WB97MD3,
    tasks=["optimize"],
    name="test optimization",
    folder=rowan.get_folder("api_examples")
)

print(f"View workflow privately at: <https://labs.rowansci.com/calculation/{workflow.uuid}>")

# previously:
# workflow.wait_for_result()
# energy = workflow.data["calculations"][-1]["molecule"]["energy"]

# now, stream optimization steps as they complete; final iteration is the complete result.
for result in workflow.stream_result(poll_interval=5):
    if result.calculation_uuid:
        mols = rowan.retrieve_calculation_molecules(result.calculation_uuid)
        print(f"  {len(mols)} opt steps, energy={mols[-1].get('energy') if mols else None}")

print(result)  # <BasicCalculationResult energy=-2931.662913 H>

We’ve updated all examples to use the new typed result API. If you’re looking for a quick reference on any workflow, the examples directory in our public GitHub repo has been fully updated—we’ll be moving these examples into a more web- and agent-searchable format soon.

Coming Soon

We’re planning substantial future improvements to our API for code ergonomics and AI agent usage. Here’s some of what we plan to add:

• Usage Predictions. Before submitting a workflow, we want to offer estimates for queue time, runtime, and credit cost. (We’ve already added some of this on the web interface; it’s just a matter of porting it over to the API.)

• Webhooks. Adding webhooks will allow for notifications when jobs complete (instead of requiring polling), simplifying integration in complex reasoning environments.

• Guides and Skills. We’re planning to write documentation specifically for AI agents so that it’s simple to build atop Rowan with no previous experience.

• Improved Error Messages. When things fail, you (or your agent) need to be able to understand what went wrong and how you can fix it. We plan to improve end-to-end error messages and increase observability to make it easier to troubleshoot simulation issues.

• CLI. We also plan to build a command-line interface so you can submit and monitor Rowan workflows directly from your terminal.

If any of these are particularly important to your work, we’d love to hear from you! Feel free to reach out or open a GitHub issue.

Building Tooling For AI Scientists

As we work to make Rowan more agent-compatible, we’re excited to be building with two early partners in this space.

bioArena

Kat and the team at bioArena started working on integrating Rowan into agentic workflows before we had even considered this area. We’ve been grateful for their support and continual benchmarking of the latest models, tools, & Rowan features, and we’re happy to continue sponsoring the bioArena agentic biology hackathons. (The latest hackathon, focused on designing TREM2 binders, is expected to have in vitro results from Adaptyv next week!)

Mirror Physics

Mirror Physics is building Axon, an interactive agent for drug discovery that orchestrates industry-leading drug-discovery tools to supercharge medicinal chemistry teams. We’re excited to partner with the team at Mirror Physics to give Axon access to Rowan’s tools: you can see early demos of our integration on their Substack, and we look forward to building more sophisticated and performant features alongside their team to drive real value in early-stage campaigns.

We’re excited to explore integration of Rowan into even more AI-powered workflows. If you’re interested in building with Rowan, please reach out! We’re very interested in meeting any builders in this space, from small startups to teams inside large pharmaceutical or materials companies, and we want to make Rowan’s tools as useful as possible to the next generation of AI-powered companies.

Today, we’re releasing our biggest feature to date: free-energy perturbation (FEP), a physics-based method for predicting protein–ligand binding affinity.

In this post, we’ll briefly give some scientific context for what FEP is and why it matters, discuss Rowan’s approach to FEP and its advantages, and explain how interested companies can use Rowan FEP. (Experienced drug-discovery readers may already know exactly what FEP is and why it’s useful; if this describes you, feel free to skip the first section of this post.)

What is Free-Energy Perturbation?

Free-energy perturbation (FEP) is a statistical mechanics–based technique for predicting the change in free energy between two states. The theory behind FEP is very interesting and much too complicated for this newsletter; as part of this launch, we’ve released an interactive blog post that makes it possible to explore some of the core concepts and build an intuition for what’s going on in an FEP calculation:

Most drug-discovery teams use FEP to predict the difference in binding affinity between related ligands: this is termed relative binding-affinity free-energy perturbation, or sometimes just RBFE for short. This matters because optimizing protein–ligand binding affinity is one of the crucial challenges of early-stage drug discovery. As a recent perspective by Mark Murcko highlights, the ability to identify compounds that bind a target strongly not only helps with dosage & selectivity but also gives drug designers more flexibility in optimizing biophysical properties & ADME. While there’s more to drug discovery than just binding affinity, drug designers broadly agree that knowing how modifications will impact affinity is quite useful.

Unfortunately, accurate computational prediction of binding affinity has proven very difficult. Simple single-structure methods like docking struggle to predict affinity with any predictive accuracy, while to date ML-based methods have struggled with generalization to new targets and chemical matter. FEP is noteworthy because it’s actually able to accomplish this task with high predictive validity, meaning that FEP can be used to effectively triage potential candidates in silico before needing to synthesize anything. FEP also doesn’t require existing experimental data for training, unlike QSAR-based methods, meaning that it can be used for new chemotypes or in other data-scarce regimes.

The ultimate dream of computer-assisted drug design is that scientists can design drugs in the computer, iterating quickly and cheaply to optimize their molecules without ever setting foot in the lab. While real life doesn’t quite work this way, FEP is about as close as our field has gotten to this goal—prospective studies show that compounds predicted to bind better by FEP often do bind better, with a success rate that’s substantially higher than other computational methods. When used at scale, FEP can lead to “startling efficiency gains in the overall hit-to-lead and lead optimisation process” (Chemistry World).

If all this is true, why isn’t FEP used constantly in preclinical discovery? Why doesn’t every medicinal chemist have a personal GPU running new FEP calculations around the clock to help them find the best binders possible? Two main reasons limit the broader diffusion of FEP into industry:

1. Expertise. Running FEP calculations properly is difficult and often requires specialized know-how. To get good results in a reasonable time, users must align the compounds properly, generate the graph of alchemical transformations to run, choose appropriate settings that balance speed and accuracy, actually run the calculations, and interpret the results—all of these are non-trivial for many potential users.

2. Computational cost. FEP is slow: one commonly cited figure is 10 GPU-hours per compound, although this obviously depends on a large number of factors. This runtime implies substantial real-world costs; a single FEP calculation can easily cost $20–30 worth of cloud compute time, if not more (in addition to software license fees).

While users and potential customers have been asking us about FEP for years, we’ve put this off until we thought we could offer meaningful improvements along these two dimensions. Today, we’re excited to launch a suite of tools and workflows to prepare, submit, and analyze FEP calculations that we think makes FEP dramatically faster & more accessible, with the ultimate hope of accelerating compound-discovery timelines for our customers.

Rowan’s Approach to FEP

Rowan’s FEP workflow is powered by TMD, a high-performance FEP engine built and maintained by Forrest York. TMD is based in part on the Time Machine engine developed at Relay Therapeutics, but has been extensively rewritten and optimized to achieve maximum performance on modern GPU hardware. TMD also incorporates many algorithmic improvements to improve performance and accuracy, including local resampling, adaptive lambda scheduling and Monte Carlo water sampling.

The quality of any FEP implementation is determined by accuracy (how well predicted binding affinities match experimental values) and speed (how long it takes to run the calculation). We’ve spent a good amount of time running benchmarks on Rowan FEP to try and understand how it compares to state-of-the-art methods. In our hands, Rowan FEP generally gives comparable accuracy to established methods, as assessed by both energy-based metrics (MAE and RMSE) and ranking metrics (Pearson and Spearman correlation).

We want to be as transparent as possible about the accuracy and potential limitations of Rowan FEP, so we’re launching an entirely new section of our benchmark site with interactive plots of our FEP benchmarking data. If you’re curious, feel free to go check it out! We’ve added comparisons to FEP+ (Schrödinger’s proprietary industry-standard RBFE engine) and OpenFE (the leading open-source alternative).

Where Rowan FEP really excels, though, is speed. The myriad algorithmic improvements in TMD all make it dramatically faster to run calculations through Rowan FEP. While exact timings vary based on system and settings, Rowan FEP often takes only 10–20 minutes per alchemical leg, which translates to substantially higher throughput and lower costs for the end customer. (If you find this hard to believe, so did we! Timing results for TMD are also available on our benchmark site.)

Running FEP Through Rowan

When used properly, FEP can dramatically accelerate the compound-screening pipeline and improve timelines in lead optimization campaigns. But using FEP properly requires more than just a robust and performant engine like TMD: poses must be prepared and aligned properly, graphs have to be constructed, compute hardware has to be allocated, and so on.

We’ve divided the end-to-end FEP workflow into three high-level stages:

1. Pose preparation. FEP requires aligned input poses of the molecules under study. Rowan’s analogue docking workflow takes a protein, a template pose, and a list of analogues and uses MCS overlay to generate aligned protein–ligand structures suitable for FEP. Users can optionally filter by docking score, PoseBusters validity, or RMSD to the template.

   

2. Graph construction. Next, the alchemical perturbation graph must be built through Rowan’s RBFE graph workflow. Users can choose between standard “greedy” mode and high-speed single-edge “star map” graph construction, as well as manually editing the graph once it’s been generated to adjust which edges will be computed.

   

3. Free-energy calculations. Finally, the RBFE calculations must be submitted and run. Users have full control over TMD settings, including simulation length, lambda overlap, and charge-assignment method, and sane default settings are provided for various use cases. Once submitted, Rowan will allocate cloud GPU resources and run the workflows, streaming per-edge results to the front end as edges complete.

   

Once the whole workflow is complete, users can view final ligand rankings, per-edge lambda overlap values, cycle closure analysis, and trajectory snapshots.

We recognize that we’ve barely scratched the surface of the different ways that users can interact with FEP, tune the settings, and analyze their results. As always, we aspire to full scientific transparency: a full tutorial is available on our documentation site, as is an end-to-end video walkthrough.

The Potential of FEP

The high-level promise of FEP has always been to accelerate drug discovery by moving compound optimization into the computer (at least partly). While the core scientific challenges have been solved for about a decade, we think that the impact of FEP has been limited by the cost, complexity, and expertise needed to apply FEP to real-life drug discovery programs.

Rowan FEP aims to change this. While we’re not yet at a stage where FEP becomes “too cheap to meter” (borrowing a phrase from Sam Altman), we expect that lowering the cost of FEP will dramatically increase the impact we can have on early-stage drug-design programs. Making it affordable for drug hunters to run FEP on hundreds or thousands of compounds before every round of synthesis will increase the number of shots on goal and help design cycles converge more quickly—leading to better drugs, discovered faster.

We’re also hoping to make it possible for more chemists to submit, manage, and analyze these calculations for themselves. Rowan FEP provides scientists an easy-to-use interface for FEP while still giving users full control of the underlying science, removing the need for scientists to write code to run FEP workflows. In 2007, John Van Drie wrote that “today’s sophisticated CADD tools only in the hands of experts will be on the desktops of medicinal chemists tomorrow”; our goal is to fulfill this prediction for FEP.

Ultimately, we think low-cost FEP can change how early-stage drug discovery operates. One can imagine a world in which RBFE calculations are run around the clock for early-stage small-molecule programs, continuously exploring the SAR landscape around all new experimental hits and triaging ideas from medicinal chemists or generative algorithms. These in silico data can be used both to triage potential synthesis candidates and to provide input data for QSAR models that can be further refined by experimental data, helping to make sure that every compound synthesized is actually a “shot on goal.”

While this vision remains science fiction at present, we hope that we can get there. We’re excited to work with interested early adopters to explore integration of Rowan FEP into automated compound prioritization systems.

How to Use Rowan FEP

We’re releasing FEP in two ways today.

Organization Access

Organization-level customers (minimum $50K/year) of Rowan will have full access to FEP. There are no special usage caps or additional fees for FEP access; we will simply charge for FEP on a per-credit basis as we do for other workflows. (We expect that typical FEP usage with default settings will cost between $5–10 of credits per edge to start, and we hope to bring this down over time.)

As usual, single-tenant or VPC deployments are available for an additional fee; reach out to our team if this is of interest!

Rowan Managed FEP

We will also be trying out fee-for-service FEP modeling. In this paradigm, Rowan scientists will run FEP and directly return predictions to your team for a flat fee of $25/ligand. You can read more about how this works operationally on our Managed FEP page.

If you’re interested in working with us this way, reach out to schedule an introductory call with our team! We’ll discuss what structural data is available and what modifications you hope to study; if we both agree that the series is a good match for FEP, we’ll proceed.

(We’ve never done fee-for-service work as a business before. It’s possible that the way in which we structure these deals will change, or that we’ll stop doing this eventually—if you’re interested in working with us and have thoughts, please let us know!)

Although we’re happy to finally be releasing FEP after months of work and testing in private beta, we know our work is far from over. We’re excited to start deploying Rowan FEP and the rest of our drug-discovery tools into real early-stage discovery programs and working alongside scientific teams to optimize performance, improve reliability, and help discover drugs faster. If you’d like to partner with Rowan, reach out! We’ll be happy to talk.

Finding the relevant and accessible solution-phase conformers of a molecule is key to accurate downstream simulation. Unfortunately, many molecules are flexible. The number of conformers grows exponentially with the number of hindered rotors, meaning that even many moderately complex drugs have far more conformers than can be systematically enumerated for a reasonable cost.

Even in cases where the number of conformers is “only” a few thousands or tens of thousands, identifying the best low-energy conformations is often non-trivial. Accurate ranking of conformers typically requires energies from dispersion-corrected density-functional theory (DFT), correct handling of solvent effects, and vibrational corrections to give an estimate of the free energy. Because these steps are too expensive to routinely run on thousands of conformers, pre-screening and filtering is typically run with lower levels of theory to reduce the size of the ensemble to a more manageable level—however, these cheaper filtering steps run the risk of incorrectly excluding relevant conformers from the final set.

At Rowan, we try to build practical tools that drive real impact on important scientific problems—accordingly, we’re always quite interested in the reports that come from internal tool-development teams in pharmaceutical companies, since these teams often identify pragmatic and useful solutions to the same problems we’re trying to solve. We were excited to find a 2020 paper from Novartis that reports ReSCoSS, a new workflow to increase efficiency of conformer filtering and ranking through a creative solvent-dependent clustering approach (more on how this works below).

Over the past few months, we’ve had the opportunity to work with Rainer Wilcken, one of the ReSCoSS developers, to adapt this same logic into Rowan. The result is our new solvent-dependent conformer search workflow, now available to all subscribing users. In this post we’ll describe (1) how ReSCoSS works, (2) how we’ve adapted this to Rowan using modern low-cost methods, and (3) why we think this is a useful addition to the modern drug-discovery toolkit.

ReSCoSS and Rowan’s Solvent-Dependent Conformer-Search Workflow

ReSCoSS stands for “Relevant Solution Conformer Sampling and Selection,” and the goal of ReSCoSS is to quickly identify potentially solution-relevant conformers from a large set of generated conformers.

The core insight behind ReSCoSS is that early conformer filtering often fails because inaccuracies in the ranking method will prematurely discard entire classes of conformers. For instance, a forcefield or a low-quality implicit-solvent method might overstabilize the “folded” conformers of a flexible molecule and erroneously discard all the “unfolded” conformers. Even if the final ranking method gets the energies right, it’s too late!

ReSCoSS addresses this by intentionally maintaining the diversity of the conformer ensemble during all filtering steps. Conformers are clustered based on their 3D properties, and conformers from every cluster are kept, even if they’re not globally lowest in energy. This means that the final conformer set always contains substantial 3D diversity, making the workflow more resilient to imperfect energies early on.

Here’s how this works in practice:

1. Conformer generation. Conformers are generated using any desired input method. After some testing, we found that iMTD-GC with GFN-FF through CREST worked well if we use a fairly high energy window (by default, 30 kcal/mol). As usual, we deduplicate conformers with PRISM Pruner.

2. Descriptor calculation. Descriptors have to be chosen that allow for conformers to be clustered based on their physical properties. In ReSCoSS, these descriptors come from COSMO-RS; in Rowan, we found that simpler descriptors like solvent-accessible surface area, polar surface area, radius of gyration, and so on were sufficient to let us distinguish different conformer families with good accuracy.

3. Clustering and selecting. With descriptors in hand, the molecular conformers are now clustered using k-means clustering. From each of the k clusters, the energy of each conformer is computed and the lowest-energy N conformers are selected. (By default, Rowan uses k=5 and N=3.)
   
   To make the procedure even more robust, the energy-based selection is done using energies in many different solvents. ReSCoSS uses ten solvents with different polarity and hydrogen-bonding parameters; by default, Rowan uses hexane, octanol, chloroform, dimethylsulfoxide, and water. For each solvent, the energy of all conformers is computed using GFN2-xTB and the ALPB solvent model, and then the lowest N conformers are selected.
   
   Since up to 5 * 3 = 15 conformers can be selected from each solvent, the maximum number of conformers that can be returned is 15 conformers/solvent * 5 solvents = 75 conformers. In practice, though, it’s common for different solvents to agree on the lowest-energy conformer from each cluster, making 20–30 output conformers more typical.

4. Final optimization and ranking. The small final conformer set is optimized using GFN2-xTB/ALPB(water) to get final optimized geometries, and then the per-conformer free energy is determined using g-xTB single-point energies, GFN2-xTB vibrational free-energy corrections from single-point Hessian calculations, and CPCM-X solvent free energies in each solvent.

The final output is a list of conformers and associated free-energy values in each of the selected solvents. This can be useful in several different ways:

• It’s simple to assess the difference between the population of different conformers in different solvents. Just compare the Boltzmann weights of a given conformer across solvents to see if e.g. it’s more stable in polar or non-polar environments!

• By comparing the overall free energy of the ensembles, you can quickly estimate the transfer free energy between solvents (and thus the partition coefficient). This is similar to the E_sol trick that’s proven to be useful for blood–brain-barrier penetrance: but while E_sol is limited to just gas–water transfer free energies, this approach allows you to compute transfer energies between any pair of solvents.

• Finally, you can also compare Boltzmann-averaged molecular properties between solvents, like radius of gyration or polar surface area. This addresses questions like “how does this molecule’s exposed polarity change between solvents?”, important for designing molecules that can mask polar functionality to diffuse through non-polar membranes.

Our team has been fortunate to have the help and guidance of Rainer Wilcken, one of the original ReSCoSS authors, in building this workflow. Rainer is now a computational chemist at Curie Bio, where he’s worked closely with Rowan to help us develop and validate our low-cost version of ReSCoSS. Here’s what Rainer has to say:

I’m excited to see Rowan develop a lower-cost solvent-dependent conformer workflow. Having a streamlined version of the ReSCoSS concept in Rowan makes it easy for us to roll out across Curie portfolio companies and stay focused on pipeline impact without worrying about managing compute infrastructure.

We’ve been very happy to work with Rainer and Curie in building out this feature, and we’re excited to be able to share this with the rest of our customers.

Running a Solvent-Dependent Conformer Search

Rowan’s solvent-dependent conformer-search workflow is available to subscribing Rowan users. To run a solvent-dependent conformer search, all you need is a molecule (and which solvents to study, if you want to change the defaults):

Once the job has finished running, you can see both (1) each conformer’s relative energy and population across all solvents and (2) the ranked list of conformers in each solvent. (You can view this calculation yourself online.)

It’s easy to compute transfer free energies and partition coefficients using the workflow’s output. Here, we can see that the logP(hexane/water) is predicted to be 4.57 for maraviroc (which, admittedly, might be protonated under physiological conditions):

You can also visualize how different internal coordinates vary in different ensembles. Displaying conformer energy as a function of the H55–N4 bond distance shows that internal hydrogen bonding is strongly favored even in water:

Finally, it’s possible to view the Boltzmann-averaged 3D properties of the entire ensemble. In this case, the strong intramolecular hydrogen bonding observed in all solvents means that maraviroc doesn’t change shape or surface area much across solvents, although it’s worth noting that the aqueous ensemble exposes slightly less total surface area and slightly more polar surface area, as we might expect. (More flexible molecules, like bifunctional degraders, will show bigger differences.)

We’re excited to release this workflow to our customers today. If you’re interested in trying this out, please reach out or subscribe! We’re working hard to bring state-of-the-art drug-discovery tools to all of our therapeutics customers and would be delighted to sit down with your team to understand your scientific challenges & how we can best accelerate your pipeline.