Science1 publisher2 min readPublished
Emulator trained on 20,000 simulated crystallisations benchmarks drug-process optimisation strategies
CMAC researchers trained a crystallisation emulator on more than 20,000 simulated experiments and ran 360 optimisation campaigns on it. The rankings describe a model of one generic process, so process teams get a cheap first comparison of strategies before committing reactor time.
The Scientist · Science desk

What happened
- Pickles, Nandiwale, Mehta and colleagues published a benchmarking framework for model-based design of experiments in crystallisation in npj Computational Materials.
- A mechanistic population balance model generated more than 20,000 synthetic crystallisation experiments to train a random forest emulator with an error below 1%.
- Twelve initial designs were followed by Gaussian-process Bayesian optimisation under six acquisition functions, for 360 emulated campaigns scored on hypervolume.
- AstraZeneca, Chiesi, Eli Lilly, Pfizer, Roche, Sanofi, Takeda and UCB jointly funded the work, carried out at the CMAC Future Manufacturing Research Hub.
Compiled by The ScientistSomething wrong?How this is made
Why it matters
- capability Because the simulated crystallisation is generic, a drugmaker can score a new optimiser on a shared process without disclosing any of its own molecules.
- decision A team weighing gradient boosting against a standard Gaussian process now has a published margin on a pharmaceutical-style process that the alternative has to close.
- precedent With eight competing drugmakers paying for one benchmark function, new crystallisation design-of-experiments methods are likely to be asked for scores against it.
The random forest learned from the population balance model's output [3], so its under-1% error describes how faithfully it copies that model. The model was in turn calibrated with experimental data from the Scale-Up CMC DataFactory, a self-driving lab [2]. A strategy that scores well on the emulator has beaten a simulation two steps removed from a real crystalliser. The forest approximates the model, and the model approximates one generic cooling-antisolvent crystallisation [1].
The starting designs mix Latin hypercube sampling, Sobol sequences and random sampling at several sample sizes [4]. If each of the twelve was paired with each of the six acquisition functions, there are 72 pairings [1], and the 360 campaigns [5] would come to five per pairing if the runs were spread evenly [2]. Random Sampling and Space Filling sit in the acquisition list beside EHVI, NEHVI and NParEGO [5]. The first two ignore the Gaussian process's predictions of where good results lie, so the hypervolume-seeking methods have a control to beat.
The authors also put a less standard optimiser, gradient boosting, through the emulator. A Gaussian process with expected improvement beat it by between 6% and 12% across differing initial conditions [7]. The largest margin is twice the smallest [4]. How a campaign starts changes how much the choice of optimiser matters.
The thing this doesn't tell you is how a hypervolume gap turns into lab time. Hypervolume [6] scores the set of trade-offs a campaign ends with. It does not count the experiments spent getting there, or the real runs that fail and have to be repeated. Running 360 campaigns [5] was practical because each one cost only compute.
The article is open access under a non-commercial, no-derivatives Creative Commons licence [10]. The abstract does not say whether the emulator itself is released as code, or which design and acquisition pairing came out on top.
I think the emulator is most useful for the job the authors describe: evaluating new and existing strategies against one another under realistic pharmaceutical conditions [8]. It is weaker as a forecast of how many real experiments a campaign will need. That use would require the population balance model to hold at every condition an optimiser visits, and the validation figure in the abstract is for the forest measured against the model [3].
What to watch
- Whether the authors release the emulator as code, so outside groups can run their own strategies against the same benchmark function.
- A lab check in which top-ranked strategies are run on a real crystalliser, such as the DataFactory, to see whether the emulator's ranking holds.
- Follow-on papers from other groups reporting new optimisers scored on this benchmark.