The "optimal" plant layout flooded on its own ground — GPU flood simulation, OpenUSD and Omniverse Kit in a generative-design loop

In short

• A generative-design tool, driven by a genetic algorithm (GA), picked a water-treatment-plant layout 6.3 % cheaper than the current plan. It got there by cutting the whole plant into a basin 1.3–3.4 m below original ground. Its flood map could not see that, because the map was run over the original ground.
• I re-ran rain and inflow over the ground each layout creates with a 2D shallow-water solver in NVIDIA Warp on the GPU. The optimum flooded at 3 facilities, and after repair it lost its lead. The result agreed with HEC-RAS 2D (flooded areas overlapping at IoU 0.94, intersection over union; danger verdicts 14/14).
• The GPU is what made this a routine step instead of a spot check: all 574 layouts plus every repair round (1,278 simulations) in about 12 minutes, and a GA that simulates every candidate it keeps inside its own search in 6–11 minutes per run.
• OpenUSD is the single record: the reviewed plans are variants of one file and the design numbers are attributes (150 checked, 0 mismatches). Omniverse Kit is the review stage, including a live "what if": raise the plant inside Kit and an AI layer answers in 125 ms while Warp confirms. With simulation this cheap, AI had no job in the search itself.
• This is the GD–AI Loop extended: the alternatives GD generates are built and flooded in a virtual site, and those simulated results become the AI's training data. 574 labelled layouts came out of the design process itself, with no survey and no manual labelling.

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

What it looks like in Omniverse

This is the GA's optimum, plan C, in Omniverse Kit (RTX). The water surface is the Warp result stored as 54 time samples in an OpenUSD file. Red marks facilities whose USD attribute wtp:flood:danger_R0 is True.

Water collects in the cut basin, surrounds the sludge basin, and reaches the clearwell edge at about 45 minutes. The clearwell is the tank that stores treated drinking water. The rest of this post explains how this frame was produced, and what it changed.

1. A design tool where hydraulics is the source of truth

The layout tool does real design calculation before any optimization:

• Sizing and compartments based on Korean design standard KDS 57: sedimentation, filters, ozone, GAC and clearwell.
• Pipe routing between actual connection points: 17 pipe systems that avoid structures.
• A hydraulic profile from inlet to clearwell (total head 7.38 m), with an evidence grade on every value.
• Side systems (backwash, recycle, sludge) solved in the same function as the main water levels.
• Optimization with a relative-layout GA, scoring 20-year life-cycle cost (LCC): earthwork, piping and pumping power.

The GA evaluated 1,702 plans. It picked plan C at 1.688 bn KRW against 1.802 bn for the current plan A. Its trick was a lower inlet: the water level sat 2.72 m below plan A's and the raw-water lift was 2.95 m smaller, which saves pumping cost. The price was a stepped basin cut into the slope.

The tool's flood check used one map, computed once per site over the original ground with no plant on it. A map like that cannot show whether a basin cut into the ground collects water.

2. Three ways to see the same flood

Method	What it is	Plan C, clearwell apron
Original-terrain flood map	What the design tool used	0 m
Depression fill (Planchon–Darboux)	Static "how deep could water pond" on the finished terrain	0.14 m
Warp 2D on finished terrain	Cut, fill and structure walls on a 2 m grid; rain plus upstream inflow; local-inertial shallow water on the GPU	0.35 m

On the finished terrain, plan C had 3 dangerous facilities: the clearwell (0.35 m), the sludge basin (0.68 m), and an overtopped washwater basin. The "danger" threshold was fixed before running: an apron depth ≥ 0.30 m, or overtopping. The apron is the 3 m strip of ground around each facility.

The check also exposed two defects in the design tool:

• Ancillary tanks had no flood constraint at all. That is why the original map already shows 0.69 m at the sludge basin, and the tool never checked it.
• One rule placed the washwater basin's wall top 2 m below the surrounding grade.

Update: the same check on 64 of the 574 GA layouts. Plan C is not an outlier. I took 64 layouts spread evenly over the cost ranking and drew each one's Warp flood on its own finished ground. 48 of the 64 have at least one facility in danger before repair. By quarter of the ranking, cheapest first, that is 15, 13, 14 and 6 of 16.

3. Feed it back — the ranking flips

The simulated water surface goes back into the design tool as a constraint. The tool re-solves the inlet level and finished grades, and the plan is simulated again until no facility is in danger. I call this step GD repair (GDR); it is deterministic.

Plan C needed its inlet level raised by 0.95 m, and its LCC rose to 1.821 bn KRW. The current plan A (1.802 bn) is ahead again.

I then ran the GA again with flooding inside the objective: every candidate it kept was simulated on its own finished ground during the search (140–322 simulations per run, 6–11 minutes on the GPU). Its arm screened by gradient boosting (GBM) found plan D on one of three seeds (1.7998 bn, no dangers under the design storm): the same arrangement as C, moved 27 m upslope.

The unit costs are assumed and A, C and D are within about 1 % of each other, so "A wins" or "D wins" would be overclaiming. The honest conclusion is that C's advantage existed only before the flood check.

A closer look at the four plans

After the flood check, A, C and D are within about 1 % of each other and B is 7 % higher. That is not enough to choose a plant layout. I rebuilt all four plans with the same code, split their life-cycle cost into parts, flooded each one under four storms, and moved the unit prices.

Where the money goes. C's 6.3 % lead came from one trade. Against A, C's inlet water level sat 2.72 m lower and its raw-water lift was 2.95 m smaller (back-calculated from the energy cost). That saved 0.80 bn KRW of pumping energy over 20 years and cost 0.55 bn more in earthwork and 0.15 bn more in pipes. The repair raised C's inlet level by 0.95 m: earthwork fell by 0.13 bn, but the pumping saving shrank by 0.26 bn, and the lead was gone.

Four storms, not one. The design storm (110 mm/h for 60 min) is one choice. Under a short intense storm (160 mm/h for 30 min) and a stress storm (140 mm/h for 60 min):

• A, B and repaired C stay safe under all four storms.
• D, the flood-aware GA's answer, fails the short and the stress storm. It is safe under the design storm it was optimised against and under the long storm (75 mm/h for 120 min). Under the short storm, water reaches the entry level of the admin and ozone-generator buildings (apron only about 0.16 m deep, but overtopping the entry level is the second danger condition); under the stress storm, the ozone-generator building. D was "found" with flooding in the objective, but only for one storm. Repaired for the stress storm, D costs 1.970 bn and becomes the most expensive of the four.

Prices move the winner. Holding each plan's repaired quantities, I moved earthwork and energy prices from half to double. C is cheapest on 43 % of that map, A on 27 %, D on 23 %, B on 7 %. No plan reaches the 75 % I set beforehand for calling a winner robust.

The four in context. None of the 554 repairable GA layouts beats the current plan A after the flood check; the cheapest of them is C itself (1.821 bn).

What this changes in the conclusion. The decision the simulation supports is narrower and more useful than "D wins":

• C's advantage existed only before the flood check (unchanged).
• The ranking among A, C and D depends on the design storm and on unit prices that are assumed here. The same loop can be rerun with real prices and the owner's design storm.
• A layout optimised against one storm should be checked against several before it is called flood-safe. In this study a flood run took about half a second on the GPU (1,278 runs in about 12 minutes), so the check is cheap.

Limit: the price map holds each plan's repaired quantities fixed; re-optimising the inlet level at every price was not done.

4. What the GPU made routine

Nothing above is a single simulation. Feeding the flood back means simulating every alternative on its own ground and every repair round again, and the flood-aware GA simulates inside its search:

Job	Simulations	GPU time (NVIDIA GB10)
All 574 layouts plus repair rounds	1,278	about 12 min
Flood-aware GA, one run	140–322	6–11 min
HEC-RAS cross-check, one plan (CPU)	1	4 min

The last row is the practical yardstick: the industry tool on a CPU needs 4 minutes for one plan; the GPU needed about 12 minutes for all 1,278. (The solvers differ, so I do not quote a ratio.) At that cost a designer checks a few finalists; on the GPU, checking what every alternative builds becomes part of the loop.

5. Can a home-made solver be trusted? HEC-RAS cross-check

I rebuilt the same case in US Army Corps of Engineers HEC-RAS 7.0.2 2D, using the same terrain, rain, inflow and 2 m cells. The project files were written directly and run from the command line, with no GUI.

• Flooded-area IoU 0.94 (the overlap of the two flooded areas, flooded meaning ≥ 0.10 m; pre-set threshold 0.70).
• Danger verdicts agree at 14/14 facilities. Clearwell 0.348 vs 0.361 m; sludge basin 0.680 vs 0.688 m.
• One miss by the strict criterion: at one shallow apron (GAC, 0.12 vs 0.28 m), the difference exceeded the pre-set tolerance. The cause is not yet identified.
• Run time: HEC-RAS took 4 min on CPU; Warp took 4.7 s on an NVIDIA GB10.

Verification also caught a bug in my own solver. Kit's bundled Warp (1.14) at first gave answers about 2 m different from Warp 1.18 outside Kit (1.68 m became 3.75 m). Loading Kit's Warp package outside Kit showed the two versions were bit-identical, so the version was not the cause.

The real cause was a time step at its stability limit next to vertical walls: the same plan gave different answers alone than in a batch. With CFL (the time-step stability number) reduced to 0.5, the solver matched a float64 reference within 0.001 m and converged under further refinement. Every stage was then re-run. A solver verified on terrain without walls is not verified for terrain with walls.

6. OpenUSD as the single record, Omniverse Kit as the review stage

• One file, the reviewed plans: plans A, C and C repaired are variants in a plan VariantSet. Switching plans in Kit takes 1.0 s.
• Design numbers as attributes: every facility's water level, grade, wall top and flood result are stored as wtp:* attributes.
• Checked on read-back: reading the file back in Kit and comparing 150 values against the pipeline gave 0 mismatches. The numbers on screen are the numbers that were computed.

Kit can also hold every alternative at once. Here the 64 layouts are laid out side by side on one stage, each on its own finished ground with its own flood:

• Pad colour: how many facilities are in danger before repair.
• Bar height: the layout's life-cycle cost after repair.
• Cyan frame: the cheapest after repair. It is rank #1, the GA optimum C, at 1.688 bn KRW before repair and 1.821 bn after. It stays the cheapest of these 64, but the current plan A (1.802 bn, not a GA layout) now beats it.

Three layouts have no bar because no feasible repaired layout exists for them. These 64 tiles are laid out on one stage for review; they are not stored as variants.

The same 64, one tile each, so every layout's water can be read:

The same Warp kernel inside Kit and outside differs by at most 0.0002 m, so the answer can be produced inside the review tool. Recomputing a new plan inside Kit was about 10× slower at first: 49 s against 4.7 s standalone. Replaying the solver loop as a CUDA graph closed that gap. On the layout I used for that test, one run inside Kit fell from 59 s to 2.0 s, with the same answer (within 0.0002 m), faster than the original loop outside Kit (6.3 s on that layout).

Kit is also where a design change can be tried live. Raising plan C's platform step by step inside Kit, a U-Net layer answered in 125 ms (median) and Warp confirmed each step; with the CUDA graph, Warp confirmed each step in 1.7 s. Warp showed no danger from +0.4 m. The U-Net, never trained on a raised platform, kept flagging the sludge basin, and from +0.8 m the clearwell again: false alarms on the safe side, which is exactly why its layer is marked unconfirmed until Warp replaces it. The companion note Design review in Omniverse Kit has the details.

The practical split today:

• Bulk computation runs outside Kit. All 574 plans plus repairs took 1,278 simulations: about 12 minutes of GPU solve time (17 minutes wall time), so about 0.5 s each in a batch.
• Review happens inside Kit, switching between computed variants.
• The USD attributes are the single record the review reads.

7. The GD–AI loop, extended: the virtual site makes the training data

In the GD–AI Loop, AI learns from the alternatives that generative design produces. This series adds a step between the two: every alternative is built and flooded in a virtual site before anything is learned. The AI then learns what a design does to the ground, not only its shape and cost.

• The data comes out of the design process. GD proposed 574 layouts. Warp flooded each one on its own finished ground, and the repair loop labelled every facility. Each sample is a terrain raster, a facility mask and 72 design features in; a max-depth map and 14 apron depths out. No field survey, no manual labelling.
• The GPU is what makes a dataset of this size practical. At about 0.5 s per simulation in a batch, labelling all 574 layouts and their repairs took about 12 minutes of GPU time, so the dataset can be rebuilt whenever the design tool or the storm changes.
• The AI is tested on designs it has not seen. 115 layouts were held out, with 58 real dangers among them. Every model is compared with a physics proxy that needs no training.
• The AI goes back into the loop in three places: screening GA children before they are simulated, ordering which layouts to simulate first, and answering instantly in a Kit review. Warp confirms what the AI picks, and each confirmation can join the dataset. I did not retrain on them in this series.
• The dataset can be looked at. The same scene builder that laid out the 64 layouts above can lay out any training sample in Kit, so a reviewer can see what the model was taught.

Eight held-out layouts as maps: the untrained proxy, the U-Net, Warp, and the U-Net's error. They are the 7 where the U-Net got a verdict wrong, plus one where the proxy missed a danger.

8. What AI did, and where it earns its place

The ground truth for 574 GA plans comes from Warp plus repair. 76 % of them flooded somewhere at first. Three ML surrogates (gradient boosting, U-Net and NVIDIA PhysicsNeMo FNO) were trained to predict the apron depth at 14 facilities from design-stage inputs, taking 3–8 ms per plan. They were compared with a physics baseline that needs no training (depression fill).

• Accurate on average, wrong at the threshold. Mean error was small (GBM: 0.014 m), but the misses fall near the 0.30 m threshold. No model had zero missed dangers (ML F1 0.926–0.965; physics baseline 0.875). In a safety check one miss is too many, so AI never gives the verdict; Warp re-simulation does.
• Choosing which plans to simulate: re-simulating in order of the original LCC, which is known without any simulation, came within 1 % of the pool's best plan in 10 simulations. There was no gap for AI to close.
• Pre-screening GA children: the GA simulated only the GBM's top 20 out of 60 children per generation. It missed the pre-set criterion (≥ 0.5 % better in 2 of 3 seeds; met in 1/3) and used about twice as many simulations as the unscreened flood-aware GA (286–322 against 140–162 per run).

The reason AI had no job in the search is the GPU: at about 0.5 s per simulation in a batch, simulating everything beat choosing cleverly. Surrogates earn their place where a person is waiting, which is a review session in Kit (above), or where one evaluation is expensive. Measuring that against criteria fixed in advance is part of the result.

9. Process and tools

The design tool stays the source of truth; simulation and AI are added around it, never in place of it. Each step and the tool behind it:

Step	Tool	What it does
Design	Custom Python/NumPy generative-design tool	KDS 57 sizing, hydraulic profile, A* pipe routing, relative-layout GA on 20-year LCC
Finished terrain	NumPy	Each layout rasterised to a 2 m grid with cut, fill and structure walls
Flood	NVIDIA Warp on an NVIDIA GB10	2D local-inertial shallow water, 4.7 s for one layout, about 0.5 s each in a batch; GPU depression fill as the static baseline
Repair (GDR)	The design tool itself	Simulated water levels fed back as constraints, re-simulated until no facility is in danger
Review	OpenUSD, Omniverse Kit 110.3 (RTX, headless for frames)	One file: a plan VariantSet for the reviewed plans, wtp:* attributes, time-sampled water; 64 layouts laid out on one stage for review
AI	scikit-learn, PyTorch, NVIDIA PhysicsNeMo	Gradient boosting (quantile), U-Net, FNO, trained on the simulation results; a physics baseline for comparison
Cross-check	HEC-RAS 7.0.2 2D, h5py	Project files written directly, run from the command line, results read from HDF5
Figures	matplotlib	Every figure in this post is generated from the saved results

Summary

Design calculation is the source of truth. Simulation matters when it changes a decision, and here it did.

• GPU (Warp): simulating what every alternative builds, and every repair, became a routine step: 1,278 runs in about 12 minutes.
• OpenUSD: the design numbers and the 3D model share one record.
• Omniverse Kit: the review stage, where a design change gets an instant answer and a physics confirmation.
• AI: trained on what the virtual site simulated — the GD–AI Loop extended. Not needed in the search at this cost; useful where a person is waiting.

Every pass/fail criterion was written to a file before running.

Open items:

• the shallow-apron difference against HEC-RAS
• retraining the AI on the confirmations it triggers (level 5 in the method post)

More in this series: a method post (which tool carries which part of the loop), a HEC-RAS cross-check of plans A, B and C, a surrogate inside Omniverse Kit for live review, a second case on road alignment, a look inside the plant (backwash balance, clearwell baffles, a surrogate), and every alternative at once (batch simulation and training data across all cases). All seven posts are collected in one LinkedIn newsletter: the GD–AI loop, extended.