Arm A: pretrained start
0.0089
Final loss · 30 fine-tuning epochs
Start with prior learning from the three fluid systems, then fine-tune the model weights on Euler.
Amplify Your Simulations
Use the runs you already have to predict new settings and plan your next batch.
597 / 600 held-out settings within tolerance
Generated research study · three repeats · 67 labelled runs per fit
What the 67 runs are
Each fit used 16 training runs, 12 development runs to choose checkpoints and 39 calibration runs to set the intervals. Each repeat was then checked on 200 separate held-out settings that were never used to fit it. Generated research data, not customer data yet.
Adapting your own uploads needs a GPU, which is off in this public demo.
Loading the evidence…
Recorded research results, not live.
Illustrative goal, not measured savings
The goal: fewer solver runs for a new problem
Each square is one solver run. The usual approach assumes a planned sweep of 100 runs. The Delta-V side is built from what one fit actually needs: 8 starting runs, 12 + 39 runs to check and calibrate the model, and one suggested batch of 8, about 67 in total.
Usual approach about 100 runs
Plan a full sweep of the settings and run all of it.
With Delta-V goal: about 60 to 70
Start from the few runs you can afford, adapt the pretrained model, predict the rest, then run only a bounded batch where it is still unsure.
- 5 to 10 starting runs
- Runs that check and calibrate the model
- Suggested next runs, inside your limits
- Runs you may not need
In our research the model was already accurate with 16 training runs, and the next-run picker saved about one batch at tighter accuracy targets. Lower total cost on a real customer solver is what we are testing now.
Four steps, using runs you already paid for
Bring your runs
Upload one ZIP of finished simulations. It is checked, and you are told exactly what to fix.
Get a fitted model
A pretrained model is adapted to your study and checked on runs it never saw.
Predict untested settings
Ask for any setting in your study's range and get the outcome with a 90% prediction interval.
Run only what helps
Set your range, accuracy target and run budget. Get the few runs worth simulating next, add their results, and stop when the model is good enough.
Waking up the modelconnecting0s
The first request after sleep can take a minute or two. You can read the project notes while it loads.
Research prototype for fluid simulations. A more robust model and more physics domains are in progress.
WORKBENCH
Workbench
Bring compatible simulation runs, adapt the pretrained model, explore untested settings and plan the next batch.
How it works
What Delta-V is for, the flow it expects, and where the saving is meant to come from.
The problem
Simulations cost money and time. Teams often plan a large batch of runs up front, many of which turn out not to be needed. Delta-V is meant to get more out of the runs you already have, so the next batch can be smaller and better aimed.
The flow
- Bring the runs you have. One ZIP: the settings of each run, its starting and final fields, and which runs are for training, checking and calibrating.
- The model adapts. A model pretrained on other fluid simulations is fine-tuned to your study, then checked on runs it never saw.
- Explore without simulating. Ask for any setting inside your study's range and get the predicted outcome with a 90% prediction interval.
- Set your limits, run only the useful few. You say which settings range matters, how accurate is enough and how many runs you can afford. Delta-V suggests a small batch inside those limits, usually 4 to 8 runs, that fills the gaps. You run them in your own solver and add the results.
- Stop when it is good enough. When the 90% prediction intervals are inside the accuracy you need across your range, you likely have enough runs for that question. Confirm with a few solver runs
Where the saving is meant to come from
Smaller batches
Ask for a handful of well-placed runs instead of a large blind sweep.
Stopping early
A stop signal tells you when more runs would not change the answer much.
Explore without another solver run
Trying a new setting is a prediction, not a simulation. Predictions still use some compute.
What it asks of you
Before the first prediction the model needs about 59 finished runs: 8 to train on, 12 to pick the best version of the model, and 39 to calibrate the prediction intervals. That cost is paid once per study. In our tests the model was already accurate with 16 training runs.
When you add finished runs later, they are saved as a new version of your study (version 2, 3 and so on). The model you already have keeps working; it still uses version 1. Re-adapt on a GPU, about 3 to 4 minutes, to include the new runs.
Where it stands today
- More accurate than standard methods when only 8 to 16 training runs are available.
- Calibrated 90% prediction intervals that held up on 200 unseen cases.
- A stop signal that never stopped too early in our tests.
- Lower total cost is showing promising early results, and we are working on it further with real solvers. The budget numbers below are your own scenario.
What a simulation run costs
Delta-V works alongside your solver. It aims to cut how many runs a study needs, so it matters most when each run takes hours. On the worked example here a solver run takes about half a second, so there is nothing to save there.
| Approach | Licence | Compute for one run |
|---|---|---|
| OpenFOAM | Free and open source. | Cloud compute only, about $0.03 to $0.10 per core-hour. One published example: a 20-million-cell steady case on 48 cores for about 10 hours cost about €24. |
| Commercial solvers such as Ansys Fluent and Simcenter STAR-CCM+ | Not published. Third-party estimates for Fluent are about $20,000 to $40,000 per user per year, plus HPC packs beyond 4 cores. STAR-CCM+ pay-per-hour licensing was reported at about $22 per wall-clock hour. | The same compute as OpenFOAM, plus licence time while the run is open. |
| Delta-V (prototype) | Not priced yet. | About half a second of CPU per predicted setting on this demo server. Adapting the model to a study takes about 3 to 4 minutes on one GPU. It still needs 67 finished solver runs per fit. |
Illustrative: one design question with 100 runs planned
Each run assumed to match the OpenFOAM example above: 48 cores for 10 hours.
| Cost item | 100-run sweep | Delta-V goal, about 67 runs |
|---|---|---|
| OpenFOAM compute | about €2,400 | about €1,600 |
| STAR-CCM+ licence hours, on top of compute | about $22,000 | about $14,700 |
| Calendar time, 4 runs at a time | about 250 h | about 170 h |
Illustrative goal, not measured savings. In our tests on a generated study, total runs ended level with the best standard workflow. Lower cost is showing promising early results and is being tested further. Prices are public estimates from October 2026, not quotes: Fluent estimates, STAR-CCM+ on AWS, OpenFOAM run cost, cloud core-hour rates.
Compared with standard surrogate models
Standard surrogate models such as Gaussian processes (GP) and POD-GP are the usual way to predict new settings from a few runs. Here is where Delta-V stands against them today, and what we are building next.
Today: measured results
All on one generated 2D flow study, three repeats.
| What we compared | Result | Status |
|---|---|---|
| Accuracy with 8 runs | Error about a third of the GP's. | Ahead |
| Runs to reach the accuracy target | 16 runs, against 24 for the other methods. At 16 runs, 597 of 600 held-out settings were within tolerance. | Ahead |
| Error at 16 runs against POD-GP | About 31% lower on kinetic energy and 52% lower on pressure RMS, as the median of three repeats. In one repeat POD-GP did better on kinetic energy. | Ahead on average |
| What it predicts | The whole flow field (density, pressure and velocity), with outcomes computed from it. Standard surrogates predict only the outcomes they were trained on. | Built |
| Calibrated 90% prediction intervals | 91.5% coverage on 200 unseen cases; 90.7% pooled over three repeats. GPs give their own intervals; we have not compared the two head to head yet. | Measured |
| Knowing when to stop | 15 of 15 stops, none too early. | Measured |
| With 24 runs or more | The GP catches up and pulls ahead. | No edge |
| Total runs for a whole study | Level with the best standard workflow. | No saving shown yet |
Vision: features in progress
| Feature | What it adds | Where it stands |
|---|---|---|
| Fewer total runs than standard workflows | The main cost saving: the same answer from fewer solver runs. | Promising early results, in progress |
| Tested on real solvers, OpenFOAM first | Evidence on real CFD studies, not generated data. | Looking for a design partner |
| Your uploads adapted live | Your own study adapted in minutes on a GPU. | Built; needs a GPU on the public site |
| Cheaper calibration | Fewer than 39 calibration runs, for example by reusing development runs. | Next research step |
| A more robust pretrained model | Better accuracy from the first few runs on new flows. | In progress |
| More physics and geometries | Beyond 2D periodic flow on a 64 × 64 grid. | Early probe on compressible flow |
| Studies that persist | Your studies survive server restarts. | Needs persistent storage |
Promising avenues
Early results that point to where the biggest gains could come from.
| Avenue | Why it looks promising | Next step |
|---|---|---|
| Smarter choice of next runs | In a replay of past studies, the next-run picker was never worse than the alternatives and saved about one batch of 4 runs at tighter accuracy targets. | Repeat with real solver runs. |
| Stopping sooner | The stop signal never stopped too early. In two of three repeats it stopped at 24 runs when 16 were already enough. | Tune it to stop sooner without stopping early. |
| Cheaper calibration | Calibration takes 39 of the 67 runs each fit needs, the largest share. | Test calibrating with the development runs. |
| A pretrained start for new physics | On compressible flow held out of pretraining, starting from the pretrained model gave a 16.3% lower final loss than starting from scratch (one setting, owner-reported). | More settings, with saved checkpoints. |
| Studies with expensive runs | Each run avoided saves hours of compute, and licence time on commercial solvers. | Measure on a partner's OpenFOAM or commercial study. |
| New outcomes from predicted fields | The model predicts whole fields, so other field-based quantities could come from the same predictions. | Check accuracy on quantities it was not tuned for. |
Your budget scenario
Compare the runs you planned with the runs you have used so far. It works on the study you have open in Try it.
Research
The tests behind Delta-V, what each one showed, and what comes next. Every number comes from recorded research runs on one generated flow study.
Loading…
What we found
- Accurate with few runs. With 16 training runs, 597 of 600 held-out settings were within tolerance, and error was clearly lower than standard methods at 8 to 16 runs (Tests 6, 8 and 8b).
- Honest uncertainty. The calibrated 90% prediction intervals covered 91.5% of 200 unseen cases (Test 7).
- Knowing when to stop. The stop signal was right in 15 of 15 runs, never too early (Test 8). An exploratory replay of the next-run picker saved about one batch at tighter targets.
All measured on one generated 2D flow study type, not customer data.
The tests behind it
Each test answered one question. Later tests built on what earlier ones showed.
-
1–3
Owner-reported
Does earlier learning help on a fluid the model never saw?
How we tested
We held one fluid system (compressible Euler flow) out of pretraining, then trained two copies on the same small amount of its data: one starting from the pretrained model, one from scratch.
The pretrained start reached a final loss of 0.0089 against 0.0107 from scratch, 16.3% lower, after 30 training passes.
Owner-reported run on one setting of the gas constant, without saved checkpoints. A fuller rerun is planned.
-
4
Baseline built
A fair baseline to compare against
How we tested
We built outcome tables for the three training systems and measured standard methods (mean, linear and Gaussian process) on them, so later results had something honest to beat.
-
5
Pipeline check
Can the model predict outcomes from settings?
How we tested
We connected the pretrained field model to scalar outcomes, so it takes a setting and returns a number, and checked every stage end to end on a GPU.
All eight checks passed. On that simple test case the standard method was still more accurate, which set up Test 6.
-
6
Measured on generated study
Does pretraining help on a new problem?
How we tested
A new generated flow study with three settings and two outcomes. We compared the pretrained model with a from-scratch model and a Gaussian process at 8, 16, 24 and 32 training runs. A first round showed the models were undertrained, so we reran with longer training.
The pretrained model reached the accuracy target with 16 runs; the other methods needed 24. At 8 runs its error was about a third of the Gaussian process's. From 24 runs on, the Gaussian process caught up and pulled ahead.
-
7
Measured on generated study
Can the prediction intervals be trusted?
How we tested
Five copies of the model each make a prediction; how much they disagree gives a raw range. We tuned that range on 39 separate runs, locked the rule, then tested it on 200 unseen cases.
The 90% prediction intervals contained the true result 91.5% of the time. The raw ranges alone were too narrow, which is why the tuning step stays.
-
8
Measured on generated study
Does choosing the next runs save runs?
How we tested
Five complete workflows, each starting from 8 runs and adding 8 at a time, repeated three times. Each one decided for itself when to stop.
Spreading runs evenly hit the accuracy target at 16 runs in all three repeats. The stop signal was right every time: 15 of 15 stops, none too early. Total runs used ended up level with the best standard workflow.
-
8b
Measured, retrospective
A tougher baseline, and a cheaper way to calibrate
How we tested
We compared against a stronger field-based method (POD with Gaussian processes) on the same runs, and tried tuning the ranges without the 39 extra runs.
The pretrained model was clearly more accurate at 8 and 16 runs, with error about 31% lower for kinetic energy and 52% lower for pressure at 16. The cheaper calibration came out too cautious, but calibrating on the 12 checking runs looks like a promising shortcut.
-
+
Exploratory replay
A smarter next-run picker
How we tested
We replayed the whole loop with every candidate solved in advance, comparing random picks, even spreading, uncertainty only, and a picker that adds runs only where the range is still too wide.
The picker was never worse than the alternatives and saved about one batch of 4 runs at the tighter accuracy targets. It also asks for fewer runs as the model improves: 5 at 16 runs, 3 at 24.
Where it stands
What holds up
- More accurate than standard methods at 8 to 16 runs, in four separate tests.
- Calibrated 90% prediction intervals, measured at 91.5% coverage.
- A reliable signal for when you have enough runs.
- A locked, repeatable test process: rules fixed before results were seen.
What comes next
- Run the workflow on a real customer solver, where each run is expensive.
- Lower total cost is showing promising early results: the next-run picker already saved about one batch at tighter accuracy targets. We are building on it.
- Make calibration cheaper using runs you already supply.
- Support more study types: so far, one generated 2D flow family on a 64 × 64 grid.
With many runs (24 or more), standard methods match or beat the pretrained model. Delta-V's advantage is when runs are scarce.
More details
The original model demo, datasets and project background. These are research records, not part of the current workflow.
- Model demoThe original model predicting the next frame of three flows, shown beside the real frame.
- Euler probeThe full record of Tests 1 to 3.
- DatasetsThe three flow systems the model was pretrained on.
- Model detailsArchitecture and checkpoint of the original model.
- Project storyWhy Delta-V was built and the choices along the way.
Inspect the pretrained model
Four recorded snapshots predict the next frame. This original checkpoint is separate from the study-adapted Workbench model.
Connecting to the model…
Download display arrays (.npy)Will the model match the next snapshot?
- Model prediction: the next selected field estimated from four earlier snapshots.
- Recorded simulation: the actual next snapshot from the original simulation.
- Where they differ: signed prediction minus reference. Read the numeric error alongside the image.
The starting pressure view falls below the release error target. Switch to Tracer to see a field that misses it.
Understand this comparison →Euler generalization probe
Euler was held out of joint pretraining, then fine-tuned on scarce data. The recorded two-arm comparison reports 16.3% lower error for the pretrained start. This is not a live prediction.
See the two-arm experiment and its limitations →One-step prediction: next frame (f4) from four recorded frames
FNO prediction
Run a prediction to compare the next state with ground
truth.
What are these numbers testing?
Relative error (rel. L2): total prediction error compared with the size of the reference field. Lower is better; it is not a percentage accuracy score.
Typical error (RMSE): error magnitude in this field’s simulation units. Different fields have different scales.
Structure match (SSIM): local image structure similarity. 1 is an exact match; it does not prove conservation or physical correctness.
These scores test one next-step prediction on a training example. Parameter-slider estimates, unseen trajectories, long rollouts, and transfer to Euler are not validated by them.
Errors use full-precision fields and ground truth resampled to 256 × 256. Self-imposed v1 target: scalar and pressure rel. L2 <15%; velocities have no quantitative target. This target is not a held-out validation claim. Display colors are quantized and can clip predictions outside the reference range.
Recorded frames: the four inputs (f0–f3) and the reference next frame (f4)
Recorded frame Solver data
Choose a sample to inspect a real field.
Four input frames and one reference next frame from a real simulation.
Step through the recorded frames
Solver data · not a prediction or rolloutAutoregressive playback: connecting to the backend
How far can the prediction follow the flow?
Use f0–f3 to predict f4, then feed each prediction back into the next four-frame input. This is a generated sequence, not recorded-frame playback. FPS controls playback speed, not inference speed.
Checking the selected system's rollout capability…
This example has ground truth only through f4.
Training windows contain five recorded frames, so generated
frames f5 onward cannot be scored here. To see measured error
for every step through f10, use this system’s official-test
clip (eleven recorded frames).
Error versus predicted step
No rollout results yet. No error curve is drawn without measured data.
We show reference comparisons to expose where predictions drift. Drift need not increase at every step. Later inference can run without a reference, but its true error cannot be measured without ground truth; validation will still matter.
Why this is the measuring stick. The served checkpoint was trained at prototype scale on slices of The Well, not on full trajectories, so training budget, not architecture, is the main bottleneck today. As training improves, the number of frames the model can generate from the same four inputs before its error crosses the target should grow. That horizon is how progress on the fluids model gets measured. We deliberately do not inject true frames mid-rollout to “boost” the output: it would hide exactly the drift this view exists to show.
Table-based outcome estimates (not the FNO) Precomputed tables
Moving these sliders changes the two numeric estimates. It does not change the recorded example or its predicted image. Values update after you pause dragging.
Simulation code units
Run history
Model demo comparisons saved in this browser only, up to 20. Workbench studies are different: they are stored on the server and listed under Workbench → Start.
Three systems. Different dynamics.
Real 2D simulations from Polymathic AI’s The Well. Six windows, two per system.
Loading dataset metadata…
What a time instance means
Each sample contains five consecutive snapshots from one simulation trajectory. Local frames t₀–t₃ are the model input; t₄ is the next-state reference. Physical times come from the sample metadata, in simulation code units. A local frame number is not physical time.
The source start index identifies the first frame in the window. Each catalog entry lists every timestamp and its spacing. The extraction did not retain the original trajectory ID or file path, so these sample IDs are not a complete trajectory catalog.
All fields are resampled to 256 × 256 for the model. The viewer
preserves the physical domain’s aspect ratio. The top timeline
loops the five recorded snapshots. Autoregressive rollout uses
three separate official-test clips (IDs begin
rollout-test-) with eleven recorded frames each:
f0–f3 seed the model and f4–f10 are the reference.
Training scale. The served checkpoint was trained on bounded slices of The Well at prototype budget, not on the full trajectory sets. This is the main reason accuracy and rollout horizon are where they are; see the Model page.
The model behind the field.
The original shared next-frame checkpoint used by the Model demo across its three systems. The Workbench serves a separate model adapted to each study; its details are on that study's Model step.
Fourier neural operator
Four snapshots in. One learned next state out.
The model receives four fields across four history frames: 16 input channels. It produces density, buoyancy or tracer (depending on the system), pressure, and two velocity components on a 256 × 256 grid.
- Checkpoint
- Waiting for service…
- Spectral modes
- 32 × 32
- Hidden channels
- 128
- Serving
- CPU · one step or bounded rollout (≤ 30 steps)
- Training data
- Prototype-scale slices of The Well, not full trajectories
- Pretraining mix
- Turbulent radiative layer (primary) + shear flow + Rayleigh–Bénard, jointly
Where the bottleneck is
The weights were trained at prototype budget on bounded slices of the dataset. That, more than the FNO architecture, sets the current accuracy and the rollout horizon. Growing the training set and budget is the main lever for this model; the rollout view is where any improvement should show up first.
Why FNO?
Fourier layers learn spatial relationships in the frequency domain, a useful architectural choice for PDE-like fields. This prototype uses a fixed inference grid; resolution-transfer performance is not established here.
A separate fast tier
Numeric parameter estimates use interpolation over precomputed tables. Their accuracy is not measured by the field comparison metrics.
Research history and limitations →Settings
Appearance
Black or light surfaces. Your choice stays in this browser.
Anonymous usage counts
Only fixed event names are sent to this app: page views, selections, completed examples and prediction success/failure. No visitor IDs or field arrays are included. Do Not Track and Global Privacy Control are respected. Counts reset when the server restarts; hosting providers may keep their own request logs. View aggregate counts
What is stored where
In this browser: your theme, the last 20 Model demo comparisons with their metrics and previews (Run history), and the access key for your Workbench studies. Display-resolution prediction arrays are cached in this tab for up to one hour. Clearing site data removes all of it, including access to your studies.
On the server: Workbench studies you upload or open, their versions, models, suggestions and reports. Delete a study from its Report step.
Advanced: loading measurements
Waiting for server startup measurement.
Open an example to measure comparison loading.
Generalization probe
Can prior fluid learning help on a fourth system?
Setup
euler_multi_quadrants_openBC is a fourth fluid
system held out entirely from joint SEM pretraining. Pretraining
used turbulent_radiative_layer_2D as the primary
set with shear_flow and
rayleigh_benard as joint co-training sets. The
question: does that prior learning help scarce-data fine-tuning
on a fluid system the model never saw?
Both arms were fine-tuned on the same scarce Euler data. Arm A started from the SEM-pretrained joint checkpoint. Arm B used the same architecture with random initialization, trained from scratch.
Arm B: from scratch
0.0107
Final loss · 30 training epochs
Start with random weights and learn on the same scarce-data Euler setup, without that prior learning.
16.3% lower error with the pretrained start
Measured during training; reported by the project owner. Both arms were reported fully converged in the 30-epoch rerun. The percentage is the reported result, not recalculated from the rounded losses above. These are aggregate losses, not the simulator's per-field relative L2 scores or its 15% acceptance target.
Important limitation: a file-selection bug limited fine-tuning to one distinct gamma value instead of the four intended. This narrows the evidence. The gamma-aware rerun is pending; new results may differ.
Run history
| Run | Fine-tune epochs | Result | Status |
|---|---|---|---|
| First | 15 | Pretrained arm ahead by 44.2% | Superseded, not used. The from-scratch arm had not converged at 15 epochs, so the gap was inflated and the comparison was not fair. |
| Rerun | 30 | Pretrained final loss 0.0089 · from-scratch final loss 0.0107 | Reported result. Both arms fully converged. Pretrained start is 16.3% lower error. |
Artifact status
-
No fine-tuned checkpoint exists. Neither the
pretrained-start arm nor the from-scratch arm was saved or
pushed. Confirmed directly against the
checkpoints/folder of the HF dataset repo. Only the losses above survive, which is why this page is static and Euler cannot run live. -
Normalization stats do exist on HF
(
stats/euler_multi_quadrants_openBC.npz), so that piece is not a blocker for wiring Euler live later. -
No parametric table for Euler exists, unlike
the three live systems. Its single dial (
gamma) is defined in code but was never built into a servable table.
Euler in the shared representation
- Native grid 512 × 512, resampled to 256 × 256 for the model.
-
Five raw fields; four map into the canonical
[scalar, pressure, velocity_x, velocity_y]vocabulary and one raw field has no canonical slot and is dropped. -
Raw velocity channels store momentum-like quantities; they are
divided by density on the way in to recover true velocity
(
derive_velocity). This transform is applied once to the seed frames only; predictions are never round-tripped through it. - One dial:
gamma.
What this experiment does and does not test
It compares two starting points for full-model training. It does not test frozen-backbone learned adapters. It is evidence in the direction of transfer to another fluid system, not proof of generalization to arbitrary physics. A trajectory-separated rerun and saved checkpoints are needed for stronger claims.
How each physics domain is meant to mature
- Single system (SEM): a single-system engineering-model experience. The three live systems are presented at this maturity level; their current implementation shares one jointly trained checkpoint.
- Several systems: demonstrate reliable shared learning across systems within fluids. Sharing weights alone does not establish that milestone.
- One unseen system: demonstrate generalization to one unseen fluid system, not universal physics generalization.
- Validated engineering model (LEM): a broader, rigorously validated engineering model within that domain; not claimed here.
The Euler result is evidence in the direction of the next step, not a claim that Delta-V has reached it. Every future domain (solid mechanics, heat transfer, electromagnetics) is meant to repeat this same climb with the same tooling, the same honesty rules and its own measured evidence. Fluids is simply the domain we started with.
Next: fix gamma selection, rerun both arms, save checkpoints and provenance, then connect a real side-by-side. A learned-adapter arm remains a separate future experiment.
Explore the three live systems →A first step toward
learned engineering tools.
What Delta-V does, how to use it, and where the evidence ends.
What Delta-V does today
Bring compatible simulation runs, adapt a pretrained Fourier Neural Operator to them, explore settings you have not simulated with calibrated intervals, and choose the next batch of runs. That workflow lives in the Workbench, for one supported study type: a 2D periodic flow on a fixed 64 × 64 grid. Its research basis is on the Evidence page.
The sections below explain the earlier work that led here: the shared next-frame model in the Model demo, the rollout view and the Euler probe. They are history and context, not additional supported study types.
A system for learned engineering surrogates, built one physics domain at a time.
Delta-V is not a fluids tool. It is the scaffolding for serving, measuring and honestly presenting learned approximations of physical systems, and fluid dynamics is the first domain we are running through that scaffolding. Each domain gets its own data, its own checkpoint, and its own climb up the same maturity ladder. What carries across domains is the workflow: a fast parameter-based estimate, a neural next-state prediction, a bounded rollout, and a reference comparison beside every result so you can see exactly where the model agrees with simulation and where it does not.
The project began in a software engineering lab. This public prototype is an invitation to test the interaction and understand its usefulness. The live fluids model uses only 2D data from The Well and complements high-fidelity simulation. Its output is not validated industrial simulation.
Fast estimates, with a reference you can inspect.
The distinction is the workflow: a numeric parameter explorer and a field-comparison viewer share one interface across three fluid systems. Open code and identifiable data make the implementation inspectable. This is a design choice, not evidence of superior accuracy or speed over other tools.
The parametric tier interpolates outcome tables for flux and turbulent velocity. The field tier uses a Fourier Neural Operator (FNO) with per-system preprocessing. Changing an outcome dial does not generate a new field initial condition: field prediction uses a selected recorded sample.
Current stage
An experimental multi-system fluid prototype: three served systems, one shared field checkpoint, six training demonstration windows, three official-test rollout clips with up to 30 generated steps, and browser-local history. Our starting point was the single-system engineering model (SEM). This shared serving setup is an early step toward a broader fluid model, but a validated large engineering model (LEM) requires evidence of generalization that this prototype does not yet provide.
The bottleneck is training scale, not architecture. The served checkpoint was trained at prototype budget on bounded slices of The Well, not on the full trajectory sets. That is the honest reason for the current accuracy and for how quickly rollout error grows. The rollout horizon (how many frames the model can generate from four inputs before crossing the error target) is the number we expect to move as training scales, and it is how we intend to measure that.
The research path is to compare per-system baselines with joint training, then evaluate generalization to unseen fluid systems (the Euler probe is the first such measurement), then open the next domain and repeat. Cross-domain or 3D generalization is not claimed.
The comparison is part of the product.
- Uneven prediction quality. Inspect relative L2, RMSE and SSIM per channel in the measured results below. The self-imposed v1 target is strictly relative L2 <15% for scalar and pressure. Some windows miss that target. Velocity channels are directional structure only; no quantitative target for this release.
- Six short windows. Two examples per system, drawn from training slices. They demonstrate behavior, not out-of-sample generalization. Each has four input snapshots and one reference next state.
- Prototype-scale training. The checkpoint was trained on bounded slices of The Well, not full trajectories. More training data and budget, not a new architecture, is the main lever left for the fluids model.
- Bounded rollout, short reference. Up to 30 generated steps on three official-test clips, but measured error exists only through f10. Beyond that there is no ground truth and no error is reported. The top timeline still shows recorded frames only.
- Fixed model grid. Fields are resampled to 256 × 256. Images use 8-bit colors; metrics use full-precision fields before display quantization.
- Parameter-estimate evaluation is open. Field errors do not validate table interpolation. The parametric tier needs its own accuracy evaluation.
- Prototype hosting and storage. Startup can take a minute or two after sleep. History lives in your browser, without synchronization or saved full-resolution result arrays.
Measured results, not a generalization claim
Measured results load when the model is ready.
| System / sample | Field | Rel. L2 | RMSE (code units) |
SSIM | Self-imposed v1 target |
|---|
Scores are computed before display quantization. Lower relative L2 and RMSE are better; SSIM measures local structural similarity (1 is an exact match). SSIM uses the reference field’s data range and is undefined for a constant reference. A dash means unavailable or undefined, never zero error.
Separate check: six official test windows
Two fixed test files per system, one window from trajectory 0 in each. These are outside the supplied notebook's train-only source path. The notebook's original validation split mixed windows from shared trajectories; these new scores do not repair that old split. Checkpoint lineage is owner-supplied, not cryptographically established. This is a small check, not a broad generalization benchmark or adapter experiment.
Loading the published test check…
| System / test window | Field | Rel. L2 | RMSE (code units) |
SSIM | Self-imposed v1 target |
|---|
Download scores and exact source identifiers → · Method and caveats →
Choices, experiments, and lessons.
A common representation for different fluids
Density, buoyancy, and tracer map to a shared scalar channel alongside pressure and x/y velocity. Per-system normalization and fixed preprocessing adapters let the same pipeline handle radiative cooling, convection, and shear mixing. These adapters map data; they are not learned neural modules. The served FNO weights are fully shared.
Spectral prediction plus table interpolation
FNO was selected as a neural-operator baseline for spatial fields. A lightweight interpolator handles numeric outcomes without running the field model. Both are available here so their different roles stay visible.
A checkpoint-selection correction
During development, the file labeled “best” retained epoch-3 weights while later training reached epoch 59 with lower validation loss (0.0366 → 0.0251). Inference was compared and the artifact corrected. The live epoch appears on the Model page. Validation loss is not the same as the per-field error shown here.
An Euler-system research probe
The code retains an adapter for
euler_multi_quadrants_openBC but excludes it
from the served fluid family. This was explored as a
generalization probe. The supplied notebook implements full
fine-tuning versus training from scratch on Euler. The owner
subsequently supplied a 30-epoch result: 0.0089 versus
0.0107 final loss, with a reported 16.3% lower error for the
pretrained start. Only one gamma value was covered instead
of four intended; checkpoints were not saved. See
the two-arm probe and caveats. A
frozen-backbone learned-adapter arm, a trajectory-separated
evaluation and comparisons across data fractions are new
work. The two-arm result points in the direction of
transfer; learned-adapter advantage is not established.
Next questions
Which comparisons help people judge a prediction? Where do errors concentrate? Are more sample windows or longer rollouts useful? Broader evaluation and clearer data provenance will guide the next iteration.
Your first exploration.
- Choose a physical system. Select cooling-driven turbulence, convection, or shear flow. Fields, samples, and ranges update together.
- Try the instant explorer. Adjust the logarithmic sliders; estimates update after you pause dragging for 150 ms. Estimate outcomes also lets you retry. These are table-based estimates in simulation code units.
- Inspect a sample. Choose a bundled window, field, and frame. Each view has a numeric color scale and preserves the physical aspect ratio.
- Run a prediction. Four history frames predict the fifth. Compare prediction, reference, and signed prediction-minus-truth. Timeline selection does not change this fixed target. The fixed one-step predictions are computed at startup and cached. Repeated requests reuse the result; they do not run the model again.
- Read the errors. Relative L2 compares error magnitude with reference magnitude; lower is better. RMSE measures typical error magnitude in the field’s units. SSIM measures structural similarity, with 1 denoting an exact match. Near-zero references can make relative error hard to interpret.
- Inspect and revisit. Zoom, expand, or download the current field. History saves metrics and a comparison preview; reopening the sample and predicting again reuses the cached prediction for the current model.
- Explore the rest. Datasets explains domains, parameters, windows, source indices, and times. Model describes the architecture. Settings controls appearance.
Built on open work.
Read the technical note and reproduction steps →
Polymathic AI’s The Well ↗
Delta-V source code ↗
Model and dataset artifacts ↗
Created by Krish Malik.