Skip to content

Experimental Design and Operating Windows for Crystallisation

For crystallisation, evaluate particle size, yield and batch variability; use candidate recommendations, equipment execution and independent measurements to identify repeatable operating conditions.

Date
2026/10/07
Author
GOPROMP
Category
Practice · 8 min read
Crystallisation decisions: candidate conditions enter batch tests, online signals and offline particle measurements are checked separately, and anomalies return to cause investigation before the next round

Shorter crystallisation time may create more fine particles, while a longer hold occupies equipment. Even with similar mean size, two batches can have different distributions that affect filtration and processing. First decide whether the task is to find better operating conditions or explain why identical conditions are not repeatable. Those goals need different experiments.

Performance targets and evaluation conditions

A target cannot stop at “increase yield”. Agree particle-size ranges, distribution width, fines fraction and how yield and total time are calculated. Include crystal form or purity when relevant. Check quality conditions first, then compare yield and time among acceptable options; a composite score should not hide failures.

Repeat existing conditions to establish baseline distributions and batch variation. Record raw-material state, seed batch, charge size, actual temperature trajectories and measurement methods. If the baseline is drifting, investigate incoming material and equipment first, or software may learn daily equipment bias as a parameter relationship. Reserve budget for replication and final confirmation rather than spending it all on new-condition search.

Candidate conditions within equipment constraints

A temperature trajectory has many degrees of freedom. Giving all of them to an algorithm can produce changes that are hard to explain or execute. Represent it initially with a few stages, combining their durations, stirring and seeding conditions into candidates. Experimental staff confirm ranges; software checks equipment ramp rates, total run time and infeasible combinations.

The first round can use experimental design to compare main factors and interactions rather than changing one parameter at a time. Treat batches and equipment runs as blocks, randomise order where practical and intersperse reference conditions. If a factor can only change for a whole run, design around that restriction; samples sharing a condition are not fully independent replicates.

Once enough valid results exist, consider a surrogate predicting properties and uncertainty. With little data, a simple response surface or Gaussian process may be easier to inspect than a complex network. Choose models for explainable errors and useful experimental guidance, not parameter count.

Optimising candidates and identifying causes

Suppose fines increase. Two explanations remain: a stage promotes new nucleation, or existing particles break during processing. Following the highest score may improve results slightly without explaining why the next batch could fail.

With domain specialists, list the differing predictions: when fines increase, how shapes change and which adjustable conditions separate the explanations. Design the next experiment and its sampling times around those differences. Its value is reducing causal uncertainty, not necessarily achieving maximum yield immediately.

If results repeat and principal errors are explained, methods such as Bayesian optimisation can search promising candidates within acceptable ranges while reserving experiments for unknown regions. **If failure causes remain unclear, first run experiments that distinguish explanations; if the process is understood, expand optimisation.** Show this branch in the recommendation interface with its reason and missing measurements.

Recommendation, scheduling and execution

AI can organise historical conditions, suggest candidates and identify patterns; optimisation algorithms calculate combinations worth testing. Task software manages sample identities, equipment occupancy, run versions and pending measurements. Equipment controls execute confirmed programs and interlocks; models cannot freely rewrite operating limits.

Recommended experiments may not all run at once. Vessels sharing a temperature bath cannot follow different trajectories independently; offline analysis takes time, and later rounds may depend on pending results. Scheduling retains these constraints and separates “run completed”, “awaiting measurement” and “anomalous result”. Incomplete results are not successes, and the model should not repeatedly recommend a candidate already underway.

Online signals and independent measurements

Online instruments observe process changes, but their signals are not necessarily final quality measures. A reflection probe, for example, measures chord-length distributions; particle-size inference needs shape and measurement models. Do not label that signal a confirmed particle-size distribution.

The experimental team checks size and shape with agreed offline methods alongside yield and necessary product properties, recording whether sampling, handling or waiting changed the sample. If analysis uses image models, manually review a sample of segmentation and size calibration. Retain disagreements between online and offline results and investigate measurement first rather than choosing the result that favours a recommendation.

Hold out complete batches, equipment runs or new conditions for validation. Randomly splitting adjacent times from one batch shares material and process history; good-looking errors may not predict the next batch. Preprocessing and model selection use training data only. Held-out results determine acceptance of that version.

Locating batch anomalies and updating models

If repeats of one candidate differ widely, first check measurement calibration and sample associations, then actual temperature, stirring and incoming material against agreed conditions. If equipment did not reach the target, the failure is execution-related, not direct evidence that the candidate is poor. Confirmed product failures remain valid results and help identify boundaries.

When execution and measurement are sound, check whether a key factor is missing from the model. Inspect errors by batch and condition to decide whether to add variables, narrow recommendation scope or run mechanism-distinguishing experiments. Retain raw records, causal hypotheses and handling decisions for anomalies. Exclusion or retesting requires a reason; automatic cleaning must not silently discard them.

Software delivery and further R&D

Test the final candidate on batches excluded from tuning against both the baseline and a simple-rule approach under comparable conditions. Report repeats, variation and failed conditions, assessing whether improvement exceeds measurement and process variability. A single best result cannot establish an operating window; new equipment or scale-up requires new checks.

Delivery includes interfaces for candidate comparison, experimental scheduling, result review and anomaly investigation, plus repeatable model configurations, processing and evaluation steps. The team can trace a recommendation to its supporting experiments and see conditions where work should pause. Evidence determines whether to improve within the acceptable region, test boundaries or first resolve causes affecting repeatability.