Every alternative, at once: batch simulation and training data with NVIDIA Warp, OpenUSD and Omniverse Kit

In short

• Each post in this series asked one design question. This one collects what they all relied on: every alternative that generative design (GD) produced was simulated in a batch, not one at a time. That covered 574 plant layouts (1,278 flood runs in 11.6 minutes of GPU solve time), 198 clearwell layouts (2 minutes), 19 road alignments, 115 review requests in Kit, and four plans under four storms.
• A batch is one array. Each alternative builds its own geometry on a shared grid, the geometries are stacked, and NVIDIA Warp advances all of them in one launch per time step. The clearwell solver and the Kit runs replay the step loop as a CUDA graph; the first flood batch used a plain step loop.
• The same arrays become three products:
  • an OpenUSD file whose values are checked on read-back;
  • an Omniverse Kit stage that shows every alternative side by side with its verdict;
  • a labelled dataset.
• The dataset taught the AI something a simple baseline could not. On a clearwell plan shape it had never seen, the surrogate made 10 wrong calls at the decision line, against 23 for the baseline.
• In the search itself the AI had no job. Simulating every alternative in the batch was already cheap. A batch is also not automatically faster per alternative; in one of my two solvers it was not.

Synthetic sites, assumed unit costs and rates, no client data. Every pass/fail rule was written to a file before its run.

This post pulls one thread out of the series: the plant-layout case, the method, the road case, the HEC-RAS cross-check, the review note and the clearwell post.

Why batch at all

Generative design is cheap at producing alternatives and expensive at checking them. In this series, the industry flood tool (HEC-RAS 2D, on a CPU) needed about 4 minutes for one plant plan. On an NVIDIA GB10, Warp simulated all 574 GA layouts plus every repair round, 1,278 runs, in about 12 minutes. The two solvers differ, so I do not quote a ratio.

The point is what the checking cost does to the workflow:

• Expensive checks: a designer checks a few finalists, after the decision is mostly made.
• Cheap batch checks: checking every alternative on the ground it creates becomes part of the GD loop. The results are also a dataset that nobody had to survey or label.

One batch, three products

1. GD parameters to geometry. Each alternative builds its consequence geometry:
   • the plant layouts: a finished-ground raster on a 2 m grid, with cut, fill, slopes and structure walls;
   • the clearwell: a basin raster on a 0.25 m grid, with its baffles.

The rasters are stacked into one array of shape B × ny × nx. All alternatives in a batch must share the grid, so the 198 clearwell layouts ran as three batches of 66, one per plan shape.

1. One launch for all of them. Every Warp kernel takes the batch index as its first dimension, so one launch per time step advances all B alternatives. The clearwell solver records its step loop as a CUDA graph; the flood batch of 1,278 runs used a plain step loop.
   • In the flood solver, one layout alone took 4.7 s; in the batch, 694 s for 1,278 runs is about 0.5 s each.
   • Inside Omniverse Kit, a CUDA graph captured per call cut one run on a test layout from 59 s to 2.0 s with the same answer (within 0.0002 m).
2. Result arrays to OpenUSD. The values that decide go into the file: reviewed plans as variants of one VariantSet, design numbers as wtp:* attributes, water as time samples, and a confirmed flag. Every file was read back in Kit and compared with the pipeline, with 0 mismatches each time:
   • plant: 150 values;
   • road: 87;
   • HEC-RAS cross-check: 280;
   • review requests: 6,810.
3. Result arrays to a Kit stage. All alternatives sit side by side. A pad shows the verdict and a bar shows the number that decides (next section).
4. Result arrays to a dataset. Inputs and labels per alternative, with whole designs held out for testing (the section after next).

Every case in this series was a batch

Case	Alternatives	Simulations	Time
Plant layouts, with repair rounds	574	1,278 Warp runs	11.6 min GPU solve (16.7 min wall)
Flood-aware GA, one run	candidates kept in the search	140–322 Warp runs	6.3–11.0 min per run
Clearwell baffle layouts	198	3 launches of 66	119 s, including inlet calibration
Review requests in Kit	115 held-out layouts	AI layer, then Warp confirmation	99 ms AI layer (median); Warp in Kit about 48 s per confirmation, 1.7 s once run as a CUDA graph
Road alignments (Case 2)	19	72 Warp runs at 10 m (with repair rounds); 25 at 2.5 m	about 3 s each in a batch
Plans A–D × four storms	4	4 storms, before and after repair	(not timed separately)
HEC-RAS cross-check (CPU)	4 plans	4	about 4 min each

All alternatives on one stage

A chart can rank alternatives. A Kit stage shows the reviewer the geometry, the water and the deciding number together, for every alternative at once. The same scene builder laid out each case:

• Pad colour: the verdict.
• Bar height: the value that decides: cost, error, disagreement, or contact time.

Plant layouts. 64 of the 574 GA layouts, spread evenly over the cost ranking, each on its own finished ground with its own flood.

• Pad colour: the number of facilities in danger before repair.
• Bar height: the life-cycle cost after repair.

48 of the 64 have at least one facility in danger before repair. These 64 are tiles laid out for review; they are not stored as variants.

Road alignments. The 16 cheapest of 19 alignments. Before repair, every one of them has 3 to 9 danger crossings.

• Pad colour: the number of danger crossings.
• Bar height: earthwork plus drainage cost.

Two solvers. Four plans, with Warp at the back, HEC-RAS in the middle and, in front, the cells that are wet in only one of them. The pads are green because the danger verdicts agree at all 56 facility aprons.

Review requests. 32 of the 115 requests. Each U-Net row sits above its Warp row; a red pad marks a wrong U-Net verdict.

Four plans × four storms. The A–D review from the main post, as maps. Plan D was optimised against the design storm; it fails the short and the stress storms.

Thirty clearwell layouts (the animation at the top). Rows are the three plan shapes. Columns are two groups, end gaps of 2 m and 5 m, each with 1, 3, 5, 7 and 9 channels. The unbaffled tank appears in both groups, so 27 of the tiles are distinct layouts. A dye pulse moves through every tank at once.

• Pad colour: green if T10/T clears the 0.687 decision line, amber if it lies between the design's 0.584 and that line, blue if it is below the design.
• Bar height: T10/T, from the full batch run to 5 T.
• Count: 8 green, 4 amber and 18 blue. Two tiles sit within 0.001 of a colour boundary, so treat them as ties.
• What the stage shows: the square plan with narrow gaps clears the line from 5 channels on. The design plan needs 7. The long plan only clears it with 9 channels and 2 m gaps.

These stage views use particle snapshots up to 1.6 T; the T10/T values come from the batch.

What the batches taught the AI

The extended GD–AI loop treats each simulated alternative as a labelled sample.

Plant layouts: 574 samples.

• Inputs: a terrain raster, a facility mask and 72 design features.
• Outputs: a max-depth map and 14 apron depths.
• Test set: every fifth layout held out, 115 layouts with 58 real dangers.

Missed dangers and false alarms at the 0.30 m line:

Model	Missed dangers	False alarms
Gradient boosting	3	1
U-Net	1	8
NVIDIA PhysicsNeMo FNO	2	7
Physics proxy, no training	9	5

No model reached zero missed dangers, so the AI never gives the verdict; Warp does.

Clearwell layouts: 198 samples.

• Inputs: the GD parameters plus two values derived from them.
• Output: T10/T.
• Cross-validated error: 0.009, against 0.056 for a fitted path-ratio line.
• On the square plan, which the model never saw in training: 10 wrong calls at the decision line out of 66, against 23 for the line.

Where the AI had no job. The batch made simulation cheap enough to replace cleverness:

• Plant: simulating in order of the cheapest original cost reached within 1 % of the best of 574 at the first budget I tested, 10 simulations. The model-guided order needed the same.
• GA screening: letting gradient boosting screen GA children met the pre-set criterion in 1 of 3 seeds. It used about twice the simulations of the unscreened flood-aware GA: 286–322 against 140–162 per run.
• Road: with 19 alignments, no model beat the cheap order (0 of 3 splits).

Where it earned a place. It earned a place when a person was waiting. In a Kit review, the U-Net painted an unconfirmed layer in about 0.1 s while Warp confirmed. Over the 115 requests it missed 1 of 58 real dangers; the untrained proxy missed 9.

What batching does not do

• It does not make every solver faster per alternative. The clearwell flow solve for 2 layouts took 0.54 s, 0.27 s each. For 66 layouts it took 37.6 s, 0.57 s each. I did not test sizes in between. There, the batch's value was bookkeeping: one launch, one result table, one dataset.
• It needs one grid per batch. Alternatives with different plan sizes run as separate groups.
• It must give the same answer as a single run. At CFL (the time-step stability number) 0.7 the flood solver gave a different answer for the same plan alone than in a batch, next to vertical walls. At 0.5 it matched a float64 reference within 0.001 m, and every stage was re-run. Check a batch against single runs before trusting it.
• The labels inherit the solver. Switching the plant labels to HEC-RAS would flip 0.17 % of them (at most 1.63 %). The clearwell labels move with the turbulence setting I could not calibrate.
• Bulk work runs outside Kit. Kit builds, checks and renders the stage. The stages show subsets: 64 of 574, 16 of 19, 32 of 115, 30 of 198.
• The loop is not closed yet. The confirmations Warp makes in review could join the dataset. I did not retrain on them in this series.

Process and tools

Step	Tool	What it does
Alternatives	Custom GD tools (Python/NumPy, GA)	Genomes → layouts, alignments, baffle arrangements, each with its cost
Geometry batch	NumPy	Consequence geometry per alternative, stacked as B × ny × nx on one grid
Simulation	NVIDIA Warp on an NVIDIA GB10	Batched kernels: shallow-water flood on a 2 m grid; lattice Boltzmann flow and particle tracking for the clearwell. Step loop as a CUDA graph in the clearwell solver and inside Kit
Criteria	JSON with hash	Pass/fail rules fixed before each run
Contract	OpenUSD	Variants, wtp:* attributes, time samples, confirmed flag; read-back checked
Review stage	Omniverse Kit 110.3 (RTX, headless)	All alternatives side by side, verdict pad and decision bar per tile; dye particles per time step
Cross-check	HEC-RAS 7.0.2 2D (CPU)	Four plans, 56 apron verdicts compared
AI	scikit-learn, PyTorch, NVIDIA PhysicsNeMo	Gradient boosting, U-Net, FNO, against a simple baseline, scored at the decision line
Figures	matplotlib, Kit viewport captures	Generated from the saved results

Site, terrain, rates and unit costs are synthetic or assumed; no real client or site data. The flood and clearwell models compare alternatives; they do not certify a design.

In this series: The "optimal" plant layout flooded on its own ground · Linking generative design to simulation (method) · Design review in Omniverse Kit · Cross-checking against HEC-RAS 2D · Case 2: the road alignment · Inside the plant · LinkedIn newsletter (all seven posts)