Parametric Study

A parametric study runs the deck several times with one parameter (or up to four) stepped between two values, records every KPI of each run and plots any KPI or parameter against any other. Use it to see how sensitive a design is to a step time, a feed flow, a pressure, an isotherm parameter or any other input, before you hand the problem to the optimiser. To rank many uncertain inputs at once, or to put error bars on the KPIs, use a sensitivity study.

Open it from Parametric Study in the Navigator (or /workspace?tool=parametric-study). The sweep is set up and tabulated in the central panel; its plot docks on the right, in the Sweep plot window.

Configure the KPIs first. The study records the KPIs of every component that is tracked, with feed and product endpoints ticked, under Cycle Design → KPI Configuration (see Performance Metrics). There is no component to choose in the panel: track the ones you want to see. The panel warns you if no component is tracked.

Setting up a sweep

Parameter. Each row of the table is one parameter to vary, with its Start, Stop and Steps. Pick the input from the searchable list. The list is the engine's parameter registry, the one the Python package uses: step times, inlet flows, temperatures and compositions, boundary pressures, pump settings, bed and wall properties, layer properties, isotherm and kinetic parameters, and your global variables. It holds only the numbers the model uses as configured, so every run of a sweep really differs: a cycle whose steps have their own times lists the step times and not the total cycle time (and a cycle set up as fractions of the total time lists the total and the fractions), a ramped inlet temperature lists the ramp's start and end rather than the constant value, and a field written in terms of a global variable is left out (sweep the variable instead). Entries are grouped (Cycle & boundaries, Bed & wall, Layers, Adsorbents, Isotherms, User variables) and labelled with the step and stream or layer they belong to, e.g. Feed · step time.
Start, Stop, Steps. The values are spaced evenly from Start to Stop, both included: Steps = 5 between 0.5 and 1.5 runs 0.5, 0.75, 1.0, 1.25 and 1.5. Picking a parameter fills Start and Stop with 50 % and 150 % of its current value (0 and 1 if it is zero). Enter values in the parameter's SI base unit (Pa, K, s, m, mol/s, …), whatever unit the field is displayed in elsewhere; the picker shows each value with its SI unit.
+ Add a parameter adds a second, third or fourth parameter; the sweep runs every combination of their values, the first parameter's values outermost.
Click Run sweep.

How the runs are made

Each value produces a copy of the deck with the parameter set to that number, through the same registry the list comes from. To move several inputs together, define a global variable, use it in each of them, and sweep the variable: every field written in terms of it follows.
The copies are independent, so they run in parallel on a pool of background workers, each with its own copy of the solver. The pool uses one worker fewer than your machine's processor count, with at most four. The rest of the workspace stays usable while the sweep runs, and Cancel stops the remaining runs.
Every run goes to the end of its own cycles, honouring the deck's cyclic steady state settings, so a deck that stops early at CSS also stops early in the sweep.
The KPIs recorded for a run are the values in its last logged cycle, for every tracked component. Runs that fail to solve, or whose KPI is undefined (for example a purity with no product drawn), are shown as — and left out of the plots, and the panel says how many runs failed.

Switching to another Navigator item does not cancel a sweep in progress: it keeps running in the background, and its progress and results are there when you come back.

Following a sweep

The table fills in as the sweep runs, one row per run. Its Cycle column shows the cycle each run has reached (12 / 100), updated as the solvers report, and Status says whether the run is queued, running, done (with how long it took), failed or cancelled; the KPI cells show … until the run finishes. Next to the Cancel button is a count of the runs finished so far.

The Sweep log below the table is short: one line when the sweep starts, one when each run finishes (with its time and its purity and recovery) or fails (with the solver's message), and a summary at the end, each with the time since the sweep started. A run that fails also shows its solver message on hover in the Status column.

Reading the results

The table has one row per run: its parameter values, its status, and for each tracked component its Purity, Recovery, Productivity (mass), Productivity (vol), Energy and Production rate, with their units in the header.

The Sweep plot window on the right draws whatever you choose on its X axis and Y axis: each can be one of the swept parameters or one KPI of one tracked component (Carbon Dioxide · Purity). It opens on the first parameter against the first tracked component's purity. With a parameter on the x axis the runs are joined into one line per combination of the other parameters' values (purity against feed time, one line per evacuation pressure); with a KPI on the x axis the runs are a scatter, and two KPIs against each other, such as purity against recovery, also get their Pareto front (the runs no other run beats on both, each KPI in its better direction: higher purity, lower energy) joined up. 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 run'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 run, and the table scrolls to the row.

Nothing is saved with the deck; copy the numbers from the table if you need them. To look at one case in detail, set the parameter to that value in its own panel and run the deck normally.

Example

The O₂ PSA tutorial halves the purge flow of the Arora (2021) deck by hand: the net O₂ recovery rose from 4.2 % to 34.1 % and the production-step purity fell from 88.6 % to 73.0 %. A sweep of the purge stream's molar flow (listed as Purge · inlet molar flow under Cycle & boundaries) from 0.03 to 0.13 mol/s maps the whole trade-off in one go: the table has the O₂ purity and recovery of every run, and the Sweep plot with Oxygen · Recovery on the x axis and Oxygen · Purity on the y axis draws the curve (use the production-only KPI configuration described in that tutorial for the production-step purity).