Run a simulation study

Every other recipe on this site has you drive the runs yourself: one request, one card, one press of Run Simulation, repeated. That is deliberate, and for three or four points it is the right shape.

An Ultra simulation study is the other shape. You describe a bounded experiment once, Phases compiles it into an explicit list of trials, shows you that list, and waits. When you approve it, the trials run as ordinary durable simulations, each producing its own numbered run, and the study collects the results into one ranked comparison with a recommendation and a verified CSV.

It is available to signed-in users. Guests never see it.

When a study is the right tool#

If you just want two runs and their difference, you do not need a study — see Compare and analyse runs.

Starting one#

There are two ways in.

The composer toggle. Signed in, the message box carries an Ultra Simulation button. Turning it on marks the composer border, puts a dot next to the label, and changes the placeholder to "Describe a bounded multi-trial simulation study…". It stays on until you turn it off again, so every message you send while it is lit is planned as a study.

Sweep the cooling rate for 42CrMo4 and 16MnCr5 from 860 °C at 5, 10, 20, 40 and 80 °C/s and find the slowest rate that still gives at least 90% martensite.

An explicitly multi-trial request, without the toggle. Phrases such as cooling rate sweep, parameter sweep, compare grades, compare materials, factorial study, target search, optimize parameters and process window, named alongside a simulator, are recognised as study requests on their own.

Run a cooling-rate sweep on 42CrMo4 at 5, 10, 20 and 40 °C/s.

Compare grades 42CrMo4, 34CrNiMo6 and 30CrNiMo8 under the same 880 °C heat treatment.

Two useful refusals to know about before you write the prompt:

• Asking for a spot-welding study gets a question back, not a study: "Do you want one reviewed RSW run, or a staged RSW process-window study?" RSW is deliberately outside the study engine and has its own separate, confirmation-required process-window workflow. See Sweep a weld schedule.
• Asking Phases to turn a section thickness into a cooling rate is refused outright: "Thickness-to-cooling-rate mapping is not a qualified simulator capability. Supply explicit cooling rates or a verified thermal map." It will not invent the heat-transfer step for you.

Nothing runs until you approve the plan#

The study proposes first. A card appears headed Ultra simulation study, with your goal and the revision number under it, and a warning strip reading Approval binds this exact plan digest with Approve plan and Decline buttons. While it is waiting, the composer is locked and shows Awaiting approval above.

The approval window is 30 minutes. Let it lapse and the plan expires unapproved; ask again and approve the fresh one.

The card shows you the whole plan before you commit:

Two things about that trial count are worth stating plainly. It is the exact product — materials multiplied by the axis combinations — never an estimate. And a plan that does not fit the limits is refused, not trimmed: a proposal expanding to more trials than allowed comes back as expanded study has 96 trials, above maximum_trials 64 rather than quietly dropping points.

Approving is the single irreversible confirmation on the card.

Watching it run#

The card becomes the working surface. A progress rail sits under the heading, the status word on the right moves through Running, and trials appear grouped under Trials by material and axis.

Each trial row shows its parameters in compact form — Thermal path 860 → 20 °C · Cooling 20 °C/s — then its status, and, once the child run exists, a child run N link that opens the Runs panel at that run. Completed trials carry metric badges such as Martensite 92% and Hardness 471 HV. A failed trial shows a short safe message on its own row and does not take its siblings down with it.

Each trial is a real, stored simulation run in your session, numbered in the normal sequence. A study of twenty trials consumes twenty run versions. They count against the Simulation runs meter on Settings → Usage — 100 runs for a personal workspace, 500 for an organization — so a 64-trial study is most of a personal month. Nothing in the backend reads that allowance to refuse work, so a study is never blocked by it; treat it as a planning signal rather than an enforced cap. See Workspace limits and features.

Trials run through the same durable execution path as any other long simulation, so closing the tab is safe and the card reconnects. Each trial carries a 12-hour deadline from submission. The requested parallelism on the card is the plan's ceiling, not a promise: how many children actually run at once is governed by the deployment's per-session execution slots. A study that appears to be working through its trials a few at a time is behaving normally. See Long-running simulations.

Editing a running study#

While the status is Running, the card offers Edit workflow from results. It opens a plain-language box whose own help text describes exactly what happens:

Tell the study planner what to change. It receives the verified intermediate metrics, preserves unchanged intent, and returns a fully revalidated replacement plan. A fresh approval is required and matching completed trials are retained.

Keep the completed trials, add cooling rates 35 and 45 C/s, and minimize hardness.

The planner returns a complete replacement plan, not a patch — which is why it needs a new approval, and why the revision number on the card goes up. Trials whose logical identity is unchanged between the two revisions are adopted rather than rerun, so you do not pay twice for work you already have. Decline the revision, or let its approval lapse, and the previous revision stands.

Reading the result#

A finished study leads with a deterministic block headed Agent conclusion:

• A bold Recommend line naming the winning grade, with its parameter set on the next line.
• The verified objective value, named in words: "The verified hardness is 471 HV."
• How it placed: "This setup ranked first among 18 completed HT trials (2 did not complete)."
• Supporting metrics, then derived claims with their own basis badges, then sampled sensitivities where a robust design produced them.

Under that, Trial details and Verified comparison table collapse into expandable sections once the study is terminal. The comparison table's columns are built by joining the plan's inputs to the observed metrics by trial key: trial_key, status, material, simulator, mode, then every parameter, then every metric, then error.

After the card, Phases adds a written engineering explanation in the conversation — the recommended material and parameters, the strongest comparison evidence, important warnings and failed trials, and a practical next step. It is an interpretation of the verified numbers and is written not to repeat every row.

Robust process windows, read honestly#

A robust_process_window study is the one whose wording you should read most carefully, because it is the one most easily over-quoted.

It samples control axes and uncertainty axes with a deterministic Latin-hypercube design — between 2 and 32 control candidates, between 2 and 16 uncertainty samples each — and evaluates your declared constraints at every sampled point. The recommendation policy is declared before the study runs: a minimum feasible fraction (0.9 by default), whether the objective is judged on the mean or the worst case, and whether incomplete candidates are excluded or penalised.

The conclusion then says something precise and narrow:

This candidate satisfied all declared constraints in 92% of 12 bounded uncertainty samples at this sampled control point. The surrounding sampling cell is not a certified continuous process window.

That last sentence is not boilerplate. The result is a sampled candidate point with a feasible fraction attached. It is not a proof that everything between the sampled points is also feasible.

Sensitivities are reported the same way. They are Pearson correlations over the sampled design, rendered as Cooling rate → Hardness r=0.87, and the card closes that line with "Associations are descriptive, not causal." They are not an experiment, and they are not a validation.

Download verified CSV#

A terminal study with a report offers Download verified CSV. Before handing you the file, your browser recomputes the SHA-256 of the exact bytes and compares it with the digest recorded in the report. On a mismatch it refuses with CSV integrity verification failed. and gives you nothing.

The file is named simulation-study-<workflow id>.csv and contains the comparison table verbatim — the same columns, one row per planned trial including the ones that failed, with the safe error in the error column. It is the audit export, not a re-rendering of what the table happened to be showing.

Cancelling, and partial results#

Cancel study is available at any non-terminal point. Cancellation is a recorded state transition; trials that already finished keep their runs and their artifacts.

A study that loses some trials still reports. If at least one trial produced verified metrics, the study completes as partially completed, with the conclusion naming how many did not finish. Only a study in which every trial failed is reported as failed, with the reason all_study_trials_failed.

Limits#

These are contract limits. A plan that breaks one is refused before anything runs.

What a study can and cannot vary#

Each simulator owns a fixed set of parameters, and study axes may only use them. Units are Celsius and seconds here — the study layer is not the analysis layer, which canonicalises to kelvin.

Name anything else and the plan is refused before approval, with a message reading ht does not own parameter followed by the offending name.

Targets, constraints and objectives may only use metrics the simulator actually produces — for heat treatment that is hardness_hv, cycle_duration_s and the five phase_fraction_* metrics; CCT and V-Gleeble swap cycle_duration_s for cooling_rate_c_per_s, and V-Gleeble adds max_flow_stress_mpa; phase_flow_stress produces initial_yield_mpa, necking_strain, necking_stress_mpa, engineering_uts_mpa and maximum_true_stress_mpa. Ask for a metric outside that list and the plan is refused rather than approximated.

Beyond that:

• One simulator per study. There is no study that runs a CCT sweep and a heat treatment together.
• RSW is excluded, as described above.
• Custom workspace simulators are not eligible. They have no study executor. See Custom simulators.
• Materials must resolve with the capabilities the study needs — transformation kinetics for HT, CCT and thermal V-Gleeble modes; a bulk flow surface as well for hot-tensile, hot-compression and Satoh; phase flow stress for phase_flow_stress. A grade that lacks one is refused by name, with the missing capability listed. See Capability matrix.
• Study cards persist. Reload the conversation and each study remounts under the assistant turn that started it, so a new study does not replace an earlier one.

If Ultra Simulation is not offered in your composer, it is a workspace capability rather than a setting you can find — the backend refuses a forced Ultra turn with Ultra Simulation is unavailable for this workspace rather than silently running something smaller. Ask your workspace owner.

Related#

• Compare and analyse runs — the two-run alternative
• Find the critical cooling rate — the same question, driven by hand
• Long-running simulations — status, reconnection and deadlines
• Heat treatment and CCT and TTT
• Workspace limits and features
• Known limits