Cluster

Elastic compute for sweeps and optimization

An animated demonstration of the Cluster Usage view: a monochrome ODE window opens on four empty capacity blocks above an empty node roster, workers provision block by block as a matrix of dots, running jobs distribute across the pool as dot sizes and opacities shift toward a settled load, and three nodes — worker-01 active, worker-02 provisioning, worker-03 idle — join the roster one by one before the loop resets and provisions again.

What Cluster can do

Simulation capacity has always been rationed — by licence count, by queue length, by whoever booked the workstation first. Cluster turns capacity into something you request per study: a thousand parallel evaluations when the question is worth it, nothing at all when it isn't.

What it replaces

The queue is a design constraint you didn’t choose

When a sweep costs three days of shared-cluster time, engineers stop running sweeps — they guess, and they justify the guess afterwards. That is not a compute problem; it is a design-quality problem. Cluster removes the rationing, so that asking the broader question is cheaper than defending the narrow one.

  • Traditional

    Annual licence seats, and a queue for the machines

    ODE Cluster

    Metered by vCPU-hour, and requested at the scale of one study

  • Traditional

    Hardware bought for the peak load, idle the rest of the year

    ODE Cluster

    Elastic capacity, with nothing billed while it sits idle

  • Traditional

    One operating point on a laptop, one afternoon

    ODE Cluster

    A thousand candidates, as a scheduling problem

  • Traditional

    You find out it was wasted once it has finished

    ODE Cluster

    Results stream back, a run can be stopped early, and only the evaluations that ran are billed

Capabilities

How Cluster schedules engineering work

01

Per-study elasticity

A study declares how many evaluations it needs; the scheduler fans them out and collapses the pool when the front stops moving.

An animated demonstration of the Cluster scheduler: a monochrome ODE window opens on an empty worker matrix with 640 evaluations queued, fifty worker cells arrive block by block and take on a ladder of dot sizes and opacities as the study fans out across them, and once the queue reaches zero the ladder flattens and the pool stands down to a faint field of released slots before the loop resets and requests capacity again.

02

Streaming results

Candidates return as they complete, so you can read convergence and stop early instead of paying for a full batch.

An animated demonstration of a study streaming back: a monochrome ODE window lists candidates from a sweep of wall thickness between 3.6 and 5.2 millimetres, newest at the top and not in candidate order, each chipped returned or queued as the run's returned count climbs from 416 to 418 of 640 — and then the run is stopped early, and the newest row arrives chipped stopped while the count holds where it was.

03

Deterministic runs

Each evaluation records its solver build, tolerances and seed — rerun it a year later and you get the same numbers.

An animated demonstration of a rerun: a monochrome ODE window holds two run records side by side, one from 2026-03-11 and one from 2027-08-24, and the later record's fields fill in one at a time — solver build Dassl 3.2.1, tolerance 1e-6, seed 20260311, state returned — landing on the same four values the original recorded seventeen months earlier.

Ready to build?