Linking generative design to simulation in Omniverse: a method, and where else it applies

In short

• Rendering a generative-design (GD) result in Omniverse is easy. Making the simulation change the design decision is the hard part, and the part worth writing about.
• The method I settled on is one loop with three contracts: a decision criterion written down before running, a simulation run on the geometry each design would actually create, and an OpenUSD file that carries the design numbers, alternatives and simulation results together.
• It worked on a water-treatment-plant layout: the GA's "optimal" layout flooded on its own ground and lost its lead. Each NVIDIA tool carries one part: Warp on the GPU makes simulating every alternative routine, OpenUSD carries the contract, Omniverse Kit is the live review stage, and AI fills the wait where a person is waiting.
• It also extends the GD–AI Loop: the alternatives GD generates are built and simulated in a virtual site, and those results become the AI's training data. Below: the case-by-case images, the rules I would now follow for that dataset, and a maturity path for teams that want to try it.

This is the companion to The "optimal" plant layout flooded on its own ground, which has the full results. This post is about the method: how to connect a GD tool to physics simulation and Omniverse so that the connection means something.

The decoration test

My first plan for Omniverse was to export the GD result as USD and render it. It would have looked good. It would also have changed nothing: remove Omniverse, and every number, ranking and decision stays the same.

So I started asking one question of every tool in the pipeline: if I remove this, what stops working? If the answer is "nothing", the tool is decoration. For a simulation, the bar is higher still: it has to be able to change the decision, and I have to say in advance what change would count.

One loop, three contracts

The loop has six steps (the first figure in this post). What makes it work is three contracts that hold it together.

Contract 1: the decision and its criterion are written down first

Before any simulation runs, I write to a file:

• which decision the simulation could change (here: which layout ranks first on life-cycle cost),
• what counts as a change (here: an apron depth difference of at least 0.10 m, or a facility's safe/danger verdict flipping),
• what counts as "danger" (apron depth ≥ 0.30 m, or overtopping).

This is what makes a negative result publishable. When the AI surrogates missed their pre-set criterion, that was a finding, not a failure to hide.

In practice it is a small JSON file, written and hashed before the first run. Here is an abridged and translated excerpt of mine:

{
  "scenario": {"R0_design": {"intensity_mm_h": 110, "duration_min": 60, "runoff_coef": 0.9}},
  "facility_metric": {
    "apron_depth": "max depth in the 3 m strip outside each facility",
    "danger": "apron_depth >= 0.30 m or overtop"
  },
  "effect_yes": "any plan, any facility: |apron_depth(finished terrain, Warp) - apron_depth(original-terrain map)| >= 0.10 m, or the danger verdict flips",
  "readback": {"attr_vs_calc_abs_tol_m": 0.0001, "pass": "0 mismatches"}
}

Contract 2: simulate what the design creates

A trap a GD pipeline falls into easily (mine did) is running the simulation on the context, the original site, rather than on the consequence, the site after the design is built. My design tool checked flooding against a map computed over the original ground. The GA's best layout lowered the plant into a basin cut 1.3–3.4 m into the slope, which that map cannot see by construction.

So step ③ builds the consequence geometry for every alternative: the finished terrain with cut, fill and structure walls, on a 2 m grid. Step ④ runs the physics on that geometry (a 2D shallow-water solver in NVIDIA Warp on an NVIDIA GB10: 4.7 s for a single run, about 0.5 s each in a batch, 1,278 runs in about 12 minutes of GPU time). Step ⑤ feeds the simulated water levels back into the design tool as constraints, and the layout is rebuilt and re-simulated until nothing is in danger.

The feedback step matters as much as the simulation. A simulation that only reports "this floods" leaves the designer with a warning. A simulation whose result becomes a constraint gives the designer a repaired layout and its new cost, and that is what flipped the ranking.

Is that decision an artefact of my solver? A companion note, Cross-checking a GD loop against HEC-RAS 2D, inside one USD file, reruns four of the competing plans in HEC-RAS 2D: the danger verdicts agree at all 56 facility aprons, so the decision holds.

Contract 3: OpenUSD carries the design, not just the geometry

The USD file is the contract between the design tool, the simulation and the review:

• Alternatives are variants of one file (a VariantSet). Switching layouts in Omniverse Kit takes about a second.
• Design numbers are attributes on each facility: water level, finished grade, wall top, simulated apron depth, danger flag.
• Simulation results are time samples, so the water rises on Kit's timeline.
• The round trip is checked. After writing, the file is read back in Kit and every attribute is compared with the pipeline. In this project: 150 values, 0 mismatches.

An abridged facility prim (names translated):

def Xform "Site" (variantSets = "plan") {
    variantSet "plan" = {
        "C0" {
            def Xform "cw" {
                custom string wtp:name = "clearwell"
                custom double wtp:flood:apronDepth_R0 = 0.348
                custom bool   wtp:flood:danger_R0 = 1
            }
        }
    }
}

And the read-back check, in outline:

for plan in plans:
    site.GetVariantSet("plan").SetVariantSelection(plan)
    for fac in facilities:
        got = stage.GetPrimAtPath(path(fac)).GetAttribute("wtp:flood:apronDepth_R0").Get()
        assert abs(got - pipeline[plan][fac]) <= 1e-4

Without the round-trip check, the review screen and the calculation drift apart quietly, and the reviewer ends up trusting a picture. With it, a reviewer can look at a red basin in Kit and know the number behind it is the number that was computed.

Which NVIDIA tool carries which part

Each tool earned its place by making one part of the loop possible, measured in this series:

• NVIDIA Warp on the GPU turns "check what every alternative builds" from a spot check into a routine step: all 574 layouts plus repairs in about 12 minutes, and a GA that simulates inside its own search in 6–11 minutes per run.
• OpenUSD is the contract between the design tool, the simulation and the review. Every value read back matched: 150, 280 and 6,810 values in three checks.
• Omniverse Kit is the review stage where a design change can be tried live. Raising a flooded plant step by step, the answer came in 125 ms and Warp confirmed it. Replaying Warp's solver loop as a CUDA graph cut one run inside Kit from 59 s to 2.0 s, so the confirmation arrives in about 1.7 s.
• PyTorch inside Kit (a U-Net surrogate) fills the wait while Warp confirms. It missed 1 of 58 real dangers, where an untrained proxy shown just as fast missed 9. NVIDIA PhysicsNeMo FNO did no better than the U-Net at this scale.

The split I use: bulk simulation outside Kit, review and "what if" inside Kit, and the USD attributes as the single source of truth for both.

Where AI fits, and where it does not

In the GD–AI Loop, AI learns from what generative design produces. Extended here, the labels come from simulating each GD alternative in the virtual site (next section). I tested four surrogates on 574 simulated layouts: a physics-based proxy that needs no training, plus gradient boosting, U-Net and NVIDIA PhysicsNeMo FNO trained on the simulation results. They were accurate on average, but none reached zero missed dangers, and the misses sat right at the safety threshold.

So in this method AI has one main job: suggest which alternatives to simulate first. It never gives the final verdict. Whether it is worth even that depends on three conditions:

• how expensive one evaluation is (here about 0.5 s in a batch: cheap),
• how many alternatives there are,
• whether a person is waiting for the answer in milliseconds.

The baseline to beat is always "simulate in order of the cheap objective". Here that baseline came within 1 % of the best layout in 10 simulations, and the surrogates had nothing left to improve. That is the GPU's doing: it made each simulation cheap enough to simply run them.

AI's place, case by case:

Case	One evaluation	Alternatives	Surrogate vs cheap baseline
Plant layout	0.5 s	574	No gain: the baseline came within 1 % of the best in 10 simulations; GBM pre-screening of GA children met its criterion in 1 of 3 seeds
Road alignment (Case 2)	about 3 s	19	No gain: 0 of 3 splits; the baseline needed 1–2 simulations
Review in Kit, a person waiting	48–59 s inside Kit; 2.0 s after CUDA graphs	115 what-if requests	Gain over an untrained proxy shown just as fast: a 0.1 s unconfirmed layer that missed 1 of 58 real dangers (proxy: 9); Warp replaces it

The third row is the second job: when a person is waiting in a review session, the surrogate fills the wait with a layer marked unconfirmed, and the simulation replaces it. The companion note A surrogate inside Omniverse Kit has the measurements.

The extended GD–AI loop: the virtual site as a data factory

The loop above produces more than a decision. Every alternative GD proposes is built as finished ground, flooded on the GPU and scored facility by facility. That is a labelled sample. In the plant case the design process itself produced 574 of them, with no survey and no manual labelling, in about 12 minutes of GPU time. The AI that learns from them goes back into the loop: to screen GA children, to order the evaluation, and to answer instantly in a Kit review while Warp confirms.

Rules I would follow for such a dataset, each learned in this series:

1. Label the consequence, not the context. The label must come from the simulation on what the design builds. A label from the original-ground map would have taught the AI that plan C is safe.
2. Let GD supply the diversity, then hold out by design. Take the samples from the GA's own pool across the whole cost ranking, not only the winners, and hold out whole layouts (every fifth here) so the test asks about designs the model has never seen.
3. Score at the decision threshold. Mean error looked excellent (0.014 m); the misses sat at 0.30 m. Count missed dangers and false alarms, not only the average.
4. Always include an untrained baseline. A physics proxy shown just as fast, and the cheap-objective order. Without them, any model looks useful.
5. Keep provenance in the file. Solver, version and a confirmed flag on the USD prims. Note A measured what a different solver would do to the labels: 0.17 % would flip, at most 1.63 %.
6. Rebuild the data when the design tool changes. Fixing the tank floors changed the minimum earthwork about 3×. A fix like that would invalidate every label made before it; on the GPU, rebuilding them is a re-run, not a project.
7. Test outside GD's distribution before trusting it in review. A reviewer's "what if" is not always a GA layout. Raising the plant inside Kit (Note B) measures the AI on a design change it was never trained on.

The method, case by case

Each case below says what the method needed there and where it should go next.

Plant layout: simulate every alternative on its own ground

• What the method needed: finished ground at 2 m with structure walls, because water collects against walls and in cut basins; and the GDR repair, so a flood becomes a constraint and a new cost rather than a warning.
• What it showed: 48 of 64 sampled layouts had a facility in danger before repair. The optimum lost its lead once repaired.
• Direction: keep flooding inside the search (the flood-aware GA ran 140–322 simulations per run, 6–11 minutes), and make storm scenarios a design variable rather than one fixed design storm.

Road alignment: resolve the element that controls the physics

• What the method needed: a three-stage cost (earthwork, then standard drainage, then what the simulation adds) so the simulation is not credited with what a cost table does.
• What it showed: drainage cost alone changed the winner. At 10 m the simulation could not resolve ditches and culverts. A re-run at 2.5 m (16 times the cells, 25 runs in about 80 minutes on the GPU) gave the same pattern and still no decision claim; after three repair rounds every alignment still had 1–4 danger crossings.
• Direction: model drainage at the scale of the drainage element. A finer grid alone was not enough here, so the next step is a drainage-network model, not more culverts.

HEC-RAS cross-check: check the decision, not only the solver

• What the method needed: the same terrain, rain, inflow and cells in both solvers, and both results on the same USD prims.
• What it showed: the danger verdicts agreed at all 56 facility aprons of the four competing plans; HEC-RAS was deeper by 0.02–0.12 m on average.
• Direction: cross-check the plans that compete for the decision, not a single showcase plan, and carry the solver difference into the AI's labels as a stated uncertainty.

Live review in Kit: give the reviewer an answer, and say whether it is confirmed

• What the method needed: PyTorch and Warp in the same Kit session, fixed-topology layers updated in place, and a confirmed flag on every value.
• What it showed: the instant U-Net layer missed 1 of 58 real dangers where an untrained proxy missed 9; Warp replaces it in the same session, now in 1.7 s. Raising the platform, a change the U-Net never saw in training, it kept false alarms that Warp cleared.
• Direction: colour facilities from the more accurate facility model (GBM) on top of the U-Net map, and retrain on the raised-platform confirmations so the instant layer learns the change reviewers actually try.

The four cases on one stage

Each row follows one alternative through the four steps, rendered on one Omniverse Kit stage. Row 1 is the plant layout (the GA optimum, then repaired), row 2 the road alignment (Case 2), row 3 the HEC-RAS cross-check, and row 4 the surrogate in a review session.

Row 4 shows Warp in Kit at 59 s, as measured before CUDA graphs; it now takes 1.7 s.

The same Kit stage can also hold every alternative of a case at once. Below are subsets: 64 of 574 layouts, 16 of 19 alignments, 4 plans in three rows (Warp, HEC-RAS, and where they disagree), and 32 of 115 requests. Each site sits on a pad coloured by its verdict, with a bar showing the number that decides: cost, disagreement or error. It is the step a static chart cannot do: the reviewer sees the geometry, the water and the decision value together, for all alternatives at once.

Where else this applies

The loop is not specific to flooding. Wherever a GD tool proposes something whose physical consequence the design calculation does not see, the same three contracts apply. I have now run the road row as Case 2; the other three have not been run yet.

Design problem	GD proposes	Consequence geometry (step ③)	Physics on it (step ④)	Criterion that could change the decision
Road alignment (run: Case 2)	Horizontal and vertical alignments	Cut and fill along the alignment, plus side ditches and culverts	Surface runoff and ponding along the road	Drainage cost alone flipped the earthwork ranking; the simulation's further flip (0.5 %) did not meet the pre-set rule at 10 m, nor at 2.5 m; road drainage needs its own model
Factory or fab layout	Equipment and room arrangement	Rooms, walls and equipment as built	Airflow or heat around critical zones	Temperature or airflow limit at critical equipment
Building evacuation	Corridor, stair and exit arrangement	The floor plates and exits as designed	Crowd movement under an evacuation scenario	Evacuation time against the code limit
Tunnel portal	Portal position and slope cuts	Excavated slope and portal structure	Drainage of the cut slope in heavy rain	Water reaching the portal; position ranking changes

For each, the questions are the same as above: what decision could the simulation change, is the simulation running on what the design creates, and does one USD file carry the alternatives, the numbers and the results.

Each would also yield its own training data, one labelled sample per GD alternative:

• Road: the water depth and the culverts needed at each drainage crossing.
• Fab layout: the temperature or airflow at each critical tool.
• Evacuation: the evacuation time per floor and the bottleneck locations.
• Tunnel portal: the water reaching the portal per slope-cut option.

A maturity path

Where a team stands decides what to build next. This series reached level 4. Level 5 is the next step, not done here.

Level	What the loop does	What it needs
0	Render the GD result in Omniverse	USD export. Fails the decoration test
1	Simulate what each alternative builds	Consequence geometry; a GPU solver so every alternative can be simulated, not just finalists
2	Feed the result back as a constraint	A design tool that can re-solve with the simulated values; a repair loop
3	One USD file as the contract; live review in Kit	Design numbers as attributes; a read-back check; a confirmed flag
4	The virtual site produces the AI's training data	Labels on consequence geometry; held-out designs; scoring at the threshold; an untrained baseline
5	Confirmations retrain the AI; it chooses which designs to simulate next	Active learning on the GD pool, with the same pre-set criteria

How others connect simulation to design

I compared the method with four published examples. The table below uses only what each source describes; where a source is silent, the cell says "not described", which is not the same as "does not do it".

• NVIDIA's Omniverse Blueprint for real-time CAE digital twins combines a CFD solver, an AI surrogate trained with NVIDIA PhysicsNeMo, or both, with real-time visualisation in Omniverse. Luminary Cloud used it for a real-time virtual wind tunnel; the surrogate takes a surface geometry and a wind speed and returns the flow field, and it was validated on held-out simulation fields. (NVIDIA Technical Blog, Nov 2024)
• Wistron's factory digital twin uses a PhysicsNeMo surrogate for airflow and temperature in a test room, cutting a 15-hour simulation to 3.6 seconds, and describes a recommendation system meant to place new baseboards where the thermal risk is lowest. (NVIDIA Technical Blog, Jun 2024)
• BMW's virtual factory planning runs on FactoryExplorer, built with OpenUSD and the Omniverse Kit SDK, with extensions for collision detection and for measuring whether equipment fits; the 30 % saving it cites is a projection. (NVIDIA case study)
• Autodesk Forma runs its analyses (sun hours, wind, daylight, noise and more) directly on the massing proposals being designed, and compares proposals on the same criteria while you design. (Autodesk Forma blog, May 2024)

What the comparison says about the method:

• Where AI gives the answer directly, evaluation is expensive or a person is waiting. The wind tunnel and the Wistron twin put the surrogate in the answer seat because a full simulation takes hours, or because a person is exploring in real time. In my plant case one simulation cost about 0.5 s in a batch, so the surrogate could only suggest an order. When a person was waiting in Kit (48 s per recompute before CUDA graphs), it earned a second job: the instant layer. With CUDA graphs the wait fell to 1.7 s on this grid, which shrinks that job here. These cases are consistent with the conditions in the previous section; they are not a contradiction.
• OpenUSD and Kit as a shared planning stage is established. BMW's planning shows it at factory scale. What this method adds is putting the computed design numbers on the same USD prims and checking the round trip.
• Simulating the design's own geometry is common. Forma does it at the massing stage. Wistron's recommender comes closest to feeding the result back, by turning predicted thermal risk into a placement choice. What I did not find described in these sources is the step that flipped my ranking: the simulated result going back into the design calculation as a constraint, followed by an automatic repair and a re-rank of all alternatives.

What I got wrong on the way

• I started with AI. My first version trained a flood surrogate before the design tool was trustworthy. Measured against pre-set criteria, it was barely better than a GIS approximation. The design calculation has to be right first; everything else is built around it.
• My baseline was too weak. In a second round the surrogate "won", until I noticed that simulating five layouts in earthwork order (an earlier pool) gave the same answer. A comparison is only as honest as its cheapest alternative.
• I trusted the hydraulics without drawing them. The design tool treated hydraulics as the source of truth, but I had not drawn its results. The first site sections showed tank floors floating above the finished grade. Once fixed, the minimum earthwork went from 2,570 to 7,770 m³: the model had under-counted it about 3×. Draw the design the way people read it.
• I validated the solver on the wrong terrain. It passed every check on terrain without walls, then disagreed with itself next to vertical structure walls. The bug surfaced because the same calculation inside and outside Kit did not match.
• I treated Omniverse as a renderer. That failed the decoration test. It became meaningful only when USD carried the design numbers and the review could change a decision.

A checklist before you connect GD and simulation

Question	If the answer is "no"
Is the decision and its change criterion written down before running?	You will not be able to tell a finding from noise.
Does the simulation run on the geometry the design creates?	It may be checking the site, not the design.
Does the result go back into the design as a constraint?	You get warnings, not repaired alternatives.
Does one USD file carry alternatives, numbers and results, and is the round trip checked?	The review screen and the calculation will drift apart.
Is the cheapest baseline (simulate in order of the cheap objective) in the comparison?	An AI surrogate can look better than it is.
Has the solver been cross-checked against an industry tool on the same case?	You are trusting your own code on its own word.
Is the AI's label computed on the as-built geometry, with its solver recorded?	The AI learns the context, not the design.
Is the AI tested on held-out designs, at the decision threshold, against an untrained proxy?	A low average error can hide misses at the threshold.

Process and tools

The full step-by-step table is in the main post. In short: a custom Python/NumPy GD tool, NVIDIA Warp on an NVIDIA GB10 for the flood, OpenUSD and Omniverse Kit 110.3 for review, scikit-learn, PyTorch and NVIDIA PhysicsNeMo for the surrogates, and HEC-RAS 7.0.2 2D for the cross-check.

Site, terrain and unit costs are synthetic or assumed; no real client or site data.