Optimizing chemical processes: where experiment time goes
Selecting a reaction regime today relies on a series of full-scale runs. Each point is a feedstock batch change, catalyst loading, bringing the unit to steady state, sampling, and laboratory analysis. One run takes a shift or more and yields just one point in the parameter space.
The bottleneck here is not the reactor but the number of experimental runs.
The cost of an experiment is determined not by reagents but by the time the unit and analytics are occupied: the series is planned in advance, so five to ten regimes out of hundreds of possible ones are tested.
A change of feedstock supplier or catalyst batch resets the result — the cycle has to be started over, and the decision is still made from a few points rather than the entire operating regime domain.
A surrogate reactor model removes this limitation. It is trained on what has already been accumulated: unit logs, laboratory analyses, batch certificates, parameters of past campaigns.
The model then computes the entire regime domain and shows where the response changes sharply and where it is stable — the unit tests only those points where the discrepancy with the prediction is greatest.
Thus optimization of chemical processes stops being a chain of expensive campaigns: the number of experimental runs is reduced severalfold with the same coverage, and the regime is selected from a response map rather than the latest successful experience. We explain how this is implemented in practice.
Surrogate models: measurable effect for the reactor unit
A surrogate model is a fast approximation of the reactor unit, trained on full-scale runs and the unit archive.
Reaction yield, conversion, and temperature profile are computed in seconds instead of hours of laboratory or pilot work — selecting the process regime becomes iterating through thousands of parameter combinations on the model.
Experiment is needed only where the model is not confident. We place points for full-scale runs according to a Latin hypercube method and further train the model as we go: the next parameter combination is taken in the zone of maximum prediction variance.
The number of runs is reduced by 3–5 times, and each remaining one closes a specific uncertainty rather than confirming what is already known.
The prediction of reaction yield comes with a confidence interval, not a single number.
Combinations where the interval touches the boundary for selectivity or catalyst load are filtered out before launch — regimes that will certainly hit a constraint do not make it into the pilot reactor. This saves the most expensive part of the work: unit time and catalyst resource.
The stability of the process regime relies on continuous drift monitoring: the residual between prediction and sensor readings is calculated.
When feedstock changes, the composition shifts, the residual grows — the system signals in advance that retuning is needed instead of operating the unit according to an outdated relationship.
The transition to a new feedstock batch proceeds without emergency deviations and without repeated manual regime selection from scratch.
Reactor regime optimization: from approximation to hybrid scheme
The choice of model is dictated not by fashion but by the state of the data and the cost of error.
If there is little regime history or the feedstock varies noticeably between batches, pure regression on industrial data loses accuracy outside the training range — and optimization starts leading the reactor into a risky zone.
Therefore the model variant and comparison criteria are fixed before work starts; otherwise the result cannot be justified to the process engineer.
| Variant | When it fits | Limitations |
|---|---|---|
| Regression on industrial data | Dense regime history, stable feedstock, smooth transitions | Extrapolation beyond the sample, rare regimes, catalyst drift |
| Kinetic approximation calibrated from measurements | Estimates needed at range boundaries and for new feedstock batches | Requires calibration from laboratory data, more expensive to maintain |
| Hybrid reactor model: calculation plus data correction | Calculation sets the structure, data cover unaccounted effects | Validation is more complex, versions of both parts must be stored |
| Search for optimal regime on top of the model | Model validated on held-out periods, temperature and load constraints set | Result is no more accurate than the model itself; the optimum may fall on the edge of the permissible domain |
The transition to a hybrid scheme is justified when the calculation reproduces the material balance and the data explain what physics does not describe: catalyst activity, heat removal, feedstock quality.
We put regime search as the last step — it works exactly as well as the model beneath it is reliable.
Implementation: engineering stages from audit to handover
The model implementation stages proceed in iterations: after each step the customer retains an artifact that shows progress — not a report on work, but data, configurations, and fixed boundaries.
The order is structured so that the model does not go beyond the limits confirmed by the unit history.
- Process data audit. What is actually recorded in the history: which regime parameters are logged, at what frequency, where there are gaps and manual corrections in the logs. The result is a data suitability map for each loop.
- Applicability boundaries. For which ranges of temperatures, pressures, and feedstock compositions the model is allowed to give recommendations, and where the process regulations and operator decision are mandatory.
- Model construction on selected runs, input feature selection, verification of physical consistency: the recommended regime must not contradict the known process kinetics.
- Model validation on held-out experiments. Some runs do not participate in training and serve as an independent test — we compare prediction with fact for product yield and feedstock consumption.
- Alignment with the process regulations. We check recommendations against equipment, safety, and quality constraints, and discuss discrepancies with process engineers before handover.
- Handover of the model to the customer and team training: documentation on input data, retraining, and rollback to the previous version, plus review of typical operator errors.
Each stage is closed with a fixed result, so stopping at any step does not nullify what has been done — the data, applicability boundaries, and test sets remain with the customer.
Model handover: configurations, schemes, and operating procedures
A model without a supporting framework quickly becomes a black box: training parameters are lost, the feature set is remembered approximately, and data control points are not documented.
Therefore we hand over not only the model itself but everything that allows it to be operated, checked, and retrained without our involvement.
- Model configuration and version: training parameters, feature set, validation ranges, and applicability boundary.
- Data flow scheme: the path from laboratory measurements to the model input, control points, and rules for rejecting incorrect records.
- Access rules and roles: who sees raw data, who starts retraining, who approves the rollout of a new version.
- Model maintenance procedure: which metrics are compared with fact, at what frequency, and at what discrepancy threshold retraining is triggered.
- Retraining documentation: a reproducible scenario on accumulated history, version acceptance procedure, and conditions for rollback to the previous one.
- Procedure for feedstock changes: sample volume for calibration, permissible prediction shift, and the point at which model replacement is mandatory.
- Decision log: what was changed, why, and with what result — after a year the logic can be reconstructed rather than asked about again.
We agree the composition and format of each item with the customer's engineering service before handover: descriptions, roles, and retraining thresholds are fixed in writing.
This way model updates remain within the enterprise rather than turning into permanent dependence on an external team.
Case study: how the number of experimental runs at a unit was reduced
Before
Batch reactor, three variable parameters — temperature, feedstock flow rate, and contact time. The operating procedure was selected by direct runs on a pilot unit: a plan of 46 experiments, each series taking a day with a shutdown for analysis.
Some runs were rejected due to overheating of the catalyst bed, and the planning schedule shifted every time.
What was done
We built a process calculation model in Aspen HYSYS, calibrated it against the unit's nameplate data, and on its basis trained a surrogate model — a fast approximator that returns yield and bed temperature in seconds instead of hours of numerical solution.
Then the optimizer traversed the parameter space with tens of thousands of points and selected 12 candidates spread across regimes: a set that tests different hypotheses rather than confirming the same one.
What was achieved
Experimental runs — 12 instead of 46. Time to reach operating regime decreased from six weeks to nine days.
The class of deviations "catalyst bed overheating at startup" stopped recurring: the surrogate preemptively filtered out combinations where the temperature gradient exceeded the permissible corridor.
Prediction discrepancy with experiment — 2–3% for target product yield, which was enough to make regime decisions without additional series.
The model remained with the customer: a feedstock batch change is recalculated in an hour, without stopping the unit and without a new series of experiments. Describe your task — we will come back with an estimate and a plan.
How does a surrogate model differ from rigorous kinetic calculation?
Rigorous reactor calculation is the numerical solution of kinetic equations together with heat and mass transfer. The scheme includes dozens and hundreds of stages, the system becomes stiff, and each regime is calculated iteratively.
Such a model is indispensable where the mechanism matters: side reactions, transient regimes, startup and shutdown, catalyst deactivation.
The price for this accuracy is time. One calculation takes minutes, while an optimum search needs thousands of calls: temperature, pressure, feedstock composition, flow rates, contact time.
The surrogate model removes the limitation — trained on the results of rigorous calculation, it reproduces the response, yield, and selectivity in seconds.
The speed of regime enumeration increases by orders of magnitude, and the optimizer traverses the entire domain rather than a few selected points.
The surrogate has strict applicability boundaries. It is valid within the domain covered by the training calculations: the same catalyst, the same temperature and pressure range, a similar feedstock composition.
Beyond that, extrapolation begins, and the error is not visible from the outside — the model outputs a number just as confidently.
Therefore training is built with validation: some calculations are kept in a held-out sample, and the error at the domain boundary is calculated separately. Discrepancy with the rigorous scheme is a signal that the parameter space has expanded and the surrogate needs retraining.
In practice, a combination works. The surrogate quickly selects promising regimes, the rigorous calculation checks the best ones, and new expensive calculations are added where the error is greatest. Kinetics remains the source of truth, the surrogate — an accelerator of search.
Technical concerns: accuracy, data, regime constraints
Engineering objections to surrogate models are usually the same: there is little history, beyond the tested regimes the model cannot be checked, and calculation accuracy is still lower than full-scale experience.
We address each on the merits — how this is closed at the level of the calculation scheme and operating procedure.
There is little historical data on the reactor — what will the model even show?
The lack of history is compensated by structure rather than volume: balance relationships and kinetic constraints are embedded in the model, so only quantities that depend on feedstock instability diverge. To start, several dozen campaigns with continuous recording of regime parameters are enough.
What happens beyond the tested regimes?
A surrogate model is reliable where there is something to check it against. Beyond the training sample boundary, it does not issue a recommendation but marks the point as uncertain and narrows the range to the nearest tested one.
Mastering a new regime proceeds in steps, with monitoring of prediction-to-fact discrepancy at each one.
Is the model more accurate than full-scale experience?
The process engineer's experience remains the reference. The model's task is to compute thousands of variants in minutes and filter out obviously weak ones, leaving a few candidates for full-scale testing. We measure prediction accuracy on held-out campaigns that the model did not see during training.
How does this integrate into the existing control loop?
First — advisory mode: the operator sees recommendations, a human changes setpoints, and all actions are written to the log.
We connect direct control when the prediction-to-fact discrepancy remains stably within the agreed corridor, with the manual loop preserved and a clear rollback.
Let's discuss the task and come back with an estimate and work plan
The first conversation takes about an hour and is to the point: we discuss the unit, look at which regimes have already been accumulated in the logs, and where product yield is currently being lost.
On the customer side, a process engineer who knows the operating procedure and a person with access to the process history are enough — this is sufficient to understand where a surrogate model will have an effect and where the bottleneck lies in the equipment rather than in control.
To make the project estimate substantive, it is useful to prepare the following for the task discussion:
- description of the unit and process scheme: loops, nodes, control points;
- export of regime history for the available period — DCS logs, laboratory control, manual measurements, even if some records have gaps;
- target indicators: what we consider improvement — target product yield, selectivity, feedstock consumption, or regime stability;
- constraints: regulatory boundaries, safety requirements, prohibited parameter combinations;
- the set of available control actions and what must not be changed;
- a window for the pilot stage: at which unit and during which shifts setpoints may be shifted.
The work plan comes as a document with stages, team composition, and checkpoints: data reconciliation and task formulation, model training on regime history, validation on a held-out interval, a pilot stage on one reactor with measurement of the result, then a decision on scaling based on actual metrics. Describe your task — we will come back with an estimate and a plan for your unit.
