Building a Wildfire and Landslide Digital Twin by Conversation

Overview edition · Detailed edition

Sushil J. Louis, Director, Evolutionary Computing Systems Lab; Professor, Department of Computer Science and Engineering, University of Nevada, Reno, working with Claude (Anthropic), an AI coding agent, in Claude Code.

Contents

• 1. Abstract
• 2. The first prompt (verbatim)
• 3. The agent's first response (verbatim)
• 4. What happened next
• 5. What it took from the human
• 6. Limitations and required expert review
• 7. References and data sources

1. Abstract

RenoTwin is an interactive 3D digital twin of a 51 × 113 km region around Reno, Nevada, for studying wildfire spread and post-fire debris flows on a desktop or a Meta Quest 3 headset. The first version, which simulated the 2026 Hawk Fire on Peavine Peak, took about one day. It went from a single prompt to real terrain from USGS elevation data, the fire's mapped perimeter, burn severity from satellite imagery, and a Rothermel surface fire spread model over LANDFIRE fuels. After calibrating one spread factor, the simulated fire fills the mapped perimeter in the real 106 hours. The rest was added intermittently over the following three weeks, as time allowed:

• a debris-flow likelihood model after Staley et al. (2017), with rainstorms and snow
• about 237,000 OpenStreetMap buildings and a detailed downtown
• the Floriston Fire, modelled while it was still burning (it has since been put out), from the live National Weather Service observations of the time

The human wrote 51 prompts and no code. The agent wrote the Python data pipeline, the Unity 6 application, the shaders, and the tools for testing without opening Unity. This playbook records how the conversation steered the work: what the human had to know, what the agent could and could not do, where it was wrong, and how those errors were caught. It also lists the parts that fire scientists, hydrologists and geotechnical engineers would need to verify before anyone relied on the results. No domain expert has reviewed this work.

The simulated Hawk Fire. Watch the ECSL lab's movie of the fire: youtu.be/imduuDxpxXA.

2. The first prompt (verbatim)

Saturday 5 September 2026, 18:10 PDT. Everything that follows grew from this one message.

I want a 3D simulation of the city of Reno and the surrounding area. From the California border in the west on I80, to Lockwood in the east and from Cold Springs in the North to Gardnerville in the south. My purpose is to create a 3D model that can model the spread of fires and after a fire is handled, model the probabilities of landslides and other phenomena due to snow and rain. I want an interactive digital twin of the area where I can control precipitation and other parameters, the change in surface properties caused by the fire, and then actually "see" a landslide occur when I do what-if scenario analysis. I want to produce a showcase that has good underlying science and is also very highly visually impactful, especially if I am using a VR headset like the quest, and am standing in the middle of an area about to be overrun by flames or am going to be impacted by a landslide. I am most familiar with Unity. First, ask enough to scope the project. Then, let's build a simple playable prototype where I can fly around the world and look around the area. Then I'd like to simulate the recent Hawk and Bug fires on Peavine mountain, so I can get before and after (burnt) mountain surfaces, and then change model parameters so I can get a landslide to ascertain which areas will be most affected. Be terse. Plan first, get plan approved, then go step by step to build features. I plan to hand off features to Opus or Sonnet, so for each step of the plan, tell me which I should use.

3. The agent's first response (verbatim)

The agent (Fable 5.1) first read its saved notes from an earlier Unity project on the same machine, then replied:

Context loaded (Unity 6, RTX 4060 8 GB, headless verify tooling exists). Scoping questions, with my recommendation on each so you can just say "defaults":

1. VR target. Quest standalone (mobile GPU, no HDRP, hard budget) or Quest via Link/Air Link to the PC (full RTX)? Rec: PC VR via Link, URP not HDRP. VR + 8 GB rules out HDRP at this terrain scale.

2. Terrain source. (a) Build our own Unity Terrain tiles from USGS 3DEP DEM (1 m/10 m) + NAIP aerial imagery, which gives full control to repaint burn scars and run grid models on the same cells; or (b) Cesium for Unity streaming Google 3D Tiles, which looks great instantly but cannot be repainted or coupled to the sim. Rec: (a), 10 m for the full 60x90 km box, 1 m around Peavine. Cesium optional later for downtown buildings.

3. Fire model rigor. Replay the actual Hawk/Bug perimeters from NIFC data for before/after, plus a Rothermel-style cellular automaton on LANDFIRE fuel/slope/wind for what-if? Or perimeter replay only? Rec: both. Do you have perimeter files or dates, or should I pull from NIFC/WFIGS?

4. Landslide model rigor. USGS post-fire debris-flow likelihood (Staley 2017: burn severity, slope, rainfall intensity, soil erodibility) plus an infinite-slope factor-of-safety model for shallow slides, with a DEM flow-routing runout you can watch? Or something simpler and purely visual? Rec: the published models. They are cheap to compute and defensible in a showcase.

5. Snow. Include degree-day snowmelt and rain-on-snow as a moisture input, or rain only for v1? Rec: rain only for v1, snow as a parameter later.

6. Buildings and roads. OSM extruded buildings and road ribbons for context in the fly-around? Rec: yes, but after the terrain prototype.

7. Tooling. OK to run Python (GDAL/rasterio) for the data pipeline and download roughly 5 to 15 GB of public DEM/imagery? Which Unity version do you want to use: 6000.3.3f1 or 6000.5.9f1?

8. Project location. New project at ClaudeWork/RenoTwin?

Answer any subset. I'll then write the phased plan with an Opus/Sonnet assignment per step.

The human's entire reply, four minutes later, was:

defaults on all, pull perimeters from NIFC, use 6000.5.9f1

The agent then looked up both fires, confirmed that the requested Unity version was installed, wrote an eight-phase plan (phases 0 to 7) to PLAN.md with a recommended model for each phase, and waited for approval.

4. What happened next

The work falls into six sittings. Times are Pacific Daylight Time, taken from the Claude Code session transcript. "Agent time" is the time from each prompt to the agent's last reply to it, summed over the sitting; it excludes the time the human spent looking at results. The model column records which Claude model produced the replies, which the transcript stores with every message.

In total the human sent 51 prompts. The agent made about 1,700 tool calls (shell commands, file edits, web requests, headless Unity runs) and worked for about 15 hours. The plan had assigned several phases to Claude Sonnet; the human never switched to it, so every phase was built by the model already running.

The Hawk Fire, in about a day. From the first prompt the agent built, in order: a Unity 6 project with a desktop / Meta Quest toggle; a Python pipeline that downloaded USGS 3DEP elevation⁴ and NAIP aerial imagery⁵ into 67 terrain tiles covering 51 × 113 km; the Hawk and Bug Fire perimeters from NIFC⁶ with burn severity computed from Sentinel-2 satellite imagery⁷; a Rothermel¹ surface fire spread model on LANDFIRE fuels⁸, solved by Finney's minimum travel time method²; the Staley et al.³ debris-flow likelihood model alongside an infinite-slope stability model; rainstorms; about 237,000 buildings from OpenStreetMap⁹; and an interface with two modes, fire spread and rain and landslide. The simulated Hawk Fire is held at the real containment line and, after one spread factor was calibrated, reaches it in the real 106 hours.

The simulated fire at containment (top) and the historical scar (bottom), from the same viewpoint.

The rest, as time allowed. Asked for the references behind the models, the agent re-read the USGS source and found it had swapped two coefficients in the debris-flow model; it fixed them. The buildings were rebuilt from flat grey boxes into roofs, walls and facades, and downtown Reno was modelled from OpenStreetMap's detailed building tags, including the Silver Legacy dome and the bowling stadium's ball. When the human asked for textures from Google or Bing Maps, the agent declined, because their licences forbid it, and used public-domain USGS aerial imagery instead.

In September the human asked for the Floriston Fire, then burning near the California state line. The agent found it in the national record, built a second simulation grid, fetched hourly observations from the National Weather Service¹⁰, and discovered that the recorded ignition point lay in a town the fuel map treats as non-burnable. The model, uncalibrated, burned 69 ha in the first 12 hours against the real 248 ha; the agent attributed the shortfall to the model having no ember spotting or crown fire, and chose not to fit a correction to one observation.

The simulated Floriston Fire above Interstate 80.

5. What it took from the human

The human wrote no code, but the project depended on the human throughout.

• Knowing what to ask for. The scope, the study area, the choice of fires, and the demand for real science that is also visually striking all came from the human. So did knowing Unity well enough to choose it and to judge the result.
• Seeing what the agent could not. Several of the most serious defects were found by the human looking at the running program: a fire that could not be seen spreading, a burn scar that stopped short of the containment line, ground that looked burnt before anything was lit, and a pause button that could not un-pause. In each case the agent's own tests had passed, because its test harness took a different path through the code from the running application.
• Computing judgement. Running the editor on one display and the built player on three, capping rendering at HD, deferring VR, keeping the code private until it was ready: these are decisions about hardware, performance and release that the agent proposed options for but did not make.
• Steering and restraint. The human repeatedly said "fix first, then …", asked for explanations before fixes, and deferred work (the Bug Fire, VR) to keep the project moving.

The agent supplied the rest: choosing published models and data services, writing the Python pipeline and the Unity code, building tools to test the program without opening the editor, measuring its results against real fire records, and saying plainly when it had been wrong. Its limits were real: it could not see the screen of the running program, send it keystrokes, or put on the VR headset, and it said so when those limits mattered.

6. Limitations and required expert review

No domain expert has reviewed this work. The most important caveats:

• The fire model is surface spread only, with no ember spotting and no crown fire.
• Its agreement with the Hawk Fire is partly by construction: the fire is held at the mapped containment line, and one rate-of-spread factor (2.38) was fitted so it arrives there in the real time.
• Soil properties are uniform, so the debris-flow model's soil term carries no spatial information.
• Wind is uniform across the grid, not adjusted for terrain.

The detailed edition lists, for each component, what the model assumes, what the agent checked, and what is missing.

7. References and data sources

The detailed edition has the full list, including every library used. The main sources: