Sweep
What does the response surface look like across this grid?
Exploration
Search the design space at scale
The Exploration workspace part-way through a sweep. An app window sits over a green field, its left rail holding the study — Tuner, Objective and Constraint above a pinned Simulation setup — and its canvas drawing the bouncing_ball model: a hatched ground, a spring-damper contact carrying the two swept parameters, the ball, gravity above it, and a sensor reading height out to a signal port. Four cards float past the window's edges: cluster.eval_rate on a dial at 24 a second, bouncing_ball.height as a damped wave, a three-objective pareto_front filling in at 248 evaluations, and tuner.presets holding mesh density, solver tolerance and sample count. The agent panel on the right shows the request, the reply, four tool calls and three changed files, and the dock below the canvas reads the run's progress.
What Exploration can do
A single simulation answers one question. Exploration asks thousands — wrapping any model in a study, dispatching every evaluation to the cluster, and making the search itself legible so you know when to stop.
Study setup
Ask a question of your model
Bind an FMU, SSP or Paper compute graph, then declare the question: which parameters are free, within what bounds, against which objectives and constraints. Choose the method — parameter sweep, gradient-free optimization, global sensitivity, or Monte-Carlo sampling — and Exploration handles the rest.
An Exploration window with the study on one card. gearbox_2stage.fmu is bound as FMI 2.0; three free parameters show the span this study took out of the model's own domain — ratio 4.0 to 12.0, J_load 0.8 to 3.2 kg·m², c_spring 5e3 to 2e4 N·m/rad; mass is to be minimised, with T_peak held at or under 85 °C and σ_max under 340 MPa. Four method buttons sit at the foot — Sweep, Optimize, Sensitivity, Sample — the selection moves to Optimize, and that algorithm's own settings then appear beneath it: NSGA-II, population 40, 25 generations, seed 7. Nothing has run; the study is still a draft.
Live dashboard
Watch the search converge
Candidates stream back as they land, not after the batch finishes. A convergence plot tells you whether the objective is still improving; parallel coordinates tell you which corner of the space the optimizer has committed to — and whether it has quietly collapsed onto a constraint boundary.
An Exploration window with one convergence card on its canvas. The best-so-far trace fills in from the left as evaluations come back — steeply at first, then a long shallow tail, and never rising, because a best-so-far value cannot — while the card's counter climbs from 184 to 589 of a thousand and the optimizing dock's rail advances underneath. The axis is the objective as a fraction of the first candidate, so the picture says whether the search is still improving without stating a solved figure.
Results & Pareto
Read the trade-offs
Multi-objective problems do not have an answer; they have a front. Sort and filter candidates, overlay their time-domain signals to see why one wins, read the Pareto set, and apply the chosen design back to the source model in one action — with the provenance of that choice preserved.
An Exploration window with the front on its canvas and an inspector open on the right. A cloud of evaluated designs fills in over three objectives — mass, efficiency and peak temperature — as the count goes from six hundred and twenty evaluations to a thousand. The inspector holds the selected candidate #918 at 16.20 kg, efficiency 0.9258 and 84.6 °C; its Apply to model button then fills with the app's colour and the provenance of the choice lands under it — ratio 8.63 written back to gearbox_2stage, from ratio_sweep, generation 22.
At scale
Optimization on the cluster
Every evaluation is an independent run dispatched to compute, so a thousand-candidate study is a scheduling problem rather than an overnight one. Pause when the front stops moving, stop early when a constraint is clearly violated, and pay only for the evaluations that ran.
An Exploration window with the run's terms in the left rail — eighteen workers, a budget of a thousand runs, NSGA-II, six minutes of wall time against a hundred and four minutes of CPU — and the current dispatch window on the canvas as a hundred and fifty cells. Queued slots are faint; as they come back they draw as dots shaded by the objective they found, and the runs stopped part-way on the thermal limit draw the smallest cell of all, because the compute they never spent is the point. Those kills cluster toward the end, where the search is pressing the limit. One cell lights in the app's colour, and a line under the rail reads nine minutes and nine seconds of CPU never spent.
Methods
Four ways to interrogate a design
Sweep
Optimize
Sensitivity
Sample