Optimisation

The Optimisation tool searches for the deck parameters that give the best value of a KPI, or of a weighted combination of KPIs, optionally subject to constraints on other KPIs: for example, maximise CO₂ recovery while keeping purity at or above 95 %, by varying the feed time and the evacuation pressure. Every candidate is a full cycle simulation, so the search is designed to need few evaluations.

Open it from Optimisation in the Navigator (or /workspace?tool=optimisation). The search is set up and tabulated in the central panel; its plot docks on the right, in the Optimisation plot window.

Configure the KPIs first. Objectives and constraints are KPIs of tracked components, so set up Cycle Design → KPI Configuration before you start (see Performance Metrics). If you want to fit parameters to measured data instead, use Parameterisation.

Setting up

The set-up is in three tabs, Parameters, Objectives and Constraints, each showing how many rows it holds.

Parameters. Each row of the table is one parameter to vary, with its Min and Max: pick the input from the searchable list, and + Add a parameter adds another row. The list is the same as the Parametric Study's: the engine's parameter registry, holding only the numbers the model uses as configured (a field written in terms of a global variable is left out; optimise the variable instead). Bounds are in the parameter's SI base unit. A new parameter starts with bounds of 50 % and 150 % of its current value (0 to 1 if it is zero). Narrow bounds that you know are physical save evaluations.

Objectives. Each row of the objective table is one term: Maximise or Minimise, the tracked Component, the KPI (Purity, Recovery, Productivity (mass), Productivity (vol), Energy or Production rate) and a Weight $w$. + Add an objective adds another term, and × removes one; the terms are summed into one cost (below), so the weights set how much each KPI counts against the others. KPIs have very different magnitudes (purity is a fraction, energy is in J/kg), so scale the weights to make the terms comparable.

Constraints (optional). There are none by default. + Add a constraint adds a row, one inequality each: a tracked Component, a KPI, a Sense (≥ or ≤), a Target and a Penalty coefficient $\lambda$; × removes it. Add as many as you need, for example a minimum purity and a minimum recovery at once.

Evaluations. The total number of simulations, 15 by default.

The cost the optimiser minimises

For a candidate with objective KPIs $J_i$ (weights $w_i$) and constraint KPIs $g_k$ (targets $g_k^{*}$, penalties $\lambda_k$), the cost is

with $\max(0,\,g_k - g_k^{*})$ instead for a ≤ constraint. Each constraint is a penalty, not a hard limit: a candidate may violate it slightly if that buys enough objective. Make $\lambda_k$ large compared with the objective's sensitivity (KPIs such as purity and recovery are fractions between 0 and 1, so a target of 95 % is entered as 0.95) if the constraint must hold.

The KPIs are read from the last logged cycle of each run, so set the deck's cyclic steady state criterion and cycle limit so that each candidate is converged. A candidate whose solve fails, or with any objective or constraint KPI undefined (for example a purity with no product drawn), is given the worst possible cost, so the search learns to avoid that region instead of stopping. This mirrors OptimizationCostFunction::ComputeCost in the engine's adsim/include/adsim/solver/optimisation.h, which gives such candidates a cost of 10¹⁰.

The search

The optimiser is dlib's global optimiser, the method behind dlib::find_min_global: it alternates MaxLIPO steps, which use a Lipschitz bound fitted to all evaluations so far to pick the point that could be best anywhere in the box, with trust-region steps, which refine a quadratic model around the best point found. It needs no derivatives, handles non-convex KPIs, and is deterministic for a given set of bounds and costs.

In the workspace the search state lives in the solver's WebAssembly module and is driven one candidate at a time: the module proposes a point, the workspace runs the deck with the free parameters set to that point (the engine sets them before the run; the deck itself is not edited) on a dedicated background worker, computes the KPIs and the cost, and reports the cost back. MaxLIPO uses every previous result to choose the next point, so candidates run one after another, not in parallel. Cancel stops the search. Switching to another Navigator item does not: the search keeps running in the background, and its progress and results are there when you come back.

Following a search

The candidate table grows by one row per candidate as the search runs. Its Cycle column shows the cycle the running candidate has reached (12 / 100), and Status says whether a candidate is running, done (with how long it took), failed or cancelled. Next to the Cancel button is a count of the candidates evaluated so far.

The Optimisation log below the table is short: one line when the search starts, one when each candidate finishes (with its time, its cost, its objective KPIs and its constraint KPIs (a violated constraint is marked violates ≥ 0.95, for example), and new best when it beats every earlier one) or fails (with the solver's message), and a summary at the end, each with the time since the search started. If the best candidate has a free parameter at, or within 1 % of the range of, its Min or Max, a last line says so: the optimum may lie outside the range, so widen that bound and run the search again. A candidate that fails also shows its solver message on hover in the Status column.

Results

The best candidate is the one with the lowest cost, shown in bold in the candidate table. When the search has finished or been cancelled, Apply best values to simulation writes its parameter values into the deck (one undo step, so Ctrl+Z takes them back); run the deck to inspect the result. The best: candidate N link beside it selects that candidate in the table and on the plot.

The candidate table has one row per candidate: its parameter values, its status, its Cost (in bold for the best candidate), and for each tracked component its Purity, Recovery, Productivity (mass), Productivity (vol), Energy and Production rate, with their units in the header. A candidate that failed, or with any objective or constraint KPI undefined, has no cost (—).

The Optimisation plot window on the right draws whatever you choose on its X axis and Y axis: each can be the Evaluation number, the Cost, one of the free parameters, or one KPI of one tracked component (Carbon Dioxide · Purity). It opens on the cost of each candidate against its evaluation number, with the Best so far line: a line still falling at the end means more evaluations would help. The candidates lie on no grid, so they are always drawn as points; plot a free parameter against the objective KPI to see where the search has looked, or two KPIs against each other to see the trade-off it explored. Drag to zoom, scroll to zoom about the cursor and double-click to reset, as in every plot.

The table and the plot are linked. Hover over a row and its candidate's point is ringed on the plot; click the row to select it, and the point keeps its ring until you click the row again or pick another. It works the other way too: hover over a point to highlight its row, or click it to select that candidate, and the table scrolls to the row.

The search itself does not change the deck; only Apply best values to simulation does. As in a parametric sweep, each candidate sets a parameter to a plain number, so optimise a global variable when several inputs must move together.

Tips

• Start with one or two parameters and 15–30 evaluations, then add more. The number of evaluations needed grows quickly with the number of free parameters.
• A Parametric Study of each parameter first shows which ones matter and gives sensible bounds.
• If many candidates fail, the bounds include regions where the cycle cannot run (for example a pressure ramp that never reaches the next step's pressure). Tighten them.
• Energy is only non-zero when pumps have Calculate pump power ticked (see Editing Step Boundaries); step energy sources are not counted.