Inspiration
With our three team members coming from backgrounds across physics, business, and computer science, we knew from the start we wanted to build an impactful project that combined our unique strengths and interests in a way that would help them mesh together rather than pulling the project in different directions. We also wanted to build something that would create easily understandable and measurable positive impact on the world.
We spent a large part of the first day talking with sponsors and building an understanding what made a build stand out as providing unique value in a world so saturated with new tools. Our conversations kept coming back to a few common threads: being technically substantive, having a compelling story and application, and having a functional demo.
We found that wildfire spread prediction through physics-informed deep learning was the sweet spot at the center of all of our interests, combining the technical depth of physics and software development with practical, real-world implications affecting pretty much everything, from saving communities from the trauma and economic upheaval caused by fire damage to potentially saving lives. This was also a relatively unexplored area--to the best of our knowledge, no other software exists that models future physics-based predictions of fire spread based on real-time satellite data. In fact, just two years ago during the California Eaton fire that killed 19 people and destroyed over 9,000 structures, the entire LA fire department had no idea that satellite data was available, never mind having a probabilistic prediction of future spread based on it.
Throughout the build, we kept challenging ourselves, asking ourselves, "is this legendary?". Thirty-six sleepless hours of hacking later, we are convinced that it is.
What it does
Ember uses data from multiple satellites (GOES, VIIRS, etc), broadcast every 5 minutes and physics-based machine learning modeling to generate a constantly-updating prediction map and send alerts to government officials when notable changes happen.
As each new satellite fire detection, weather update, and evacuation-zone change arrives, it gets put into one shared map grid. Every 5 minutes, the latest detections go to our physics-based fire-spread model, which updates its forecast of where the fire will go over the next 6 hours. That forecast becomes a deadline for each zone, the latest time it can start evacuating safely. If a zone is at risk, we send an alert and make a call to a duty officer to alert them of the situation.
How we built it
We split the work into three parts based on our unique strengths: Abby on the physics engine and deep learning extension, Cody on data and backend, and Linda on the frontend and presentation. Then, we combined the parts together and collaborated on the final product and story.
Data
- GOES-18 fire detections (NOAA): a scan every 5 minutes, with footprints about 2.3 × 2.8 km. Each scan is released at its real availability time.
- VIIRS 375 m detections (NASA FIRMS): finer-resolution passes a few times a day.
- HRRR winds (NOAA): hourly 3 km wind forecasts that steer the fire.
- USGS 3DEP elevation: terrain, slope and aspect.
- LANDFIRE LF2024: fuel type and canopy cover, which set how fast fire can spread.
- Census 2020: population and housing, used to weigh zones by who is in the way.
- LA County evacuation zones and OpenStreetMap facilities: the zones we rank, and the hospitals, schools and fire stations in them.
- Official timeline: the documented events of the night, for context.
Physics Modeling
Ember’s integrated forecasting system uses a custom Rust physics engine combining Rothermel surface-fire physics, wind- and terrain-driven directional spread, and level-set fire-perimeter propagation. Satellite-informed particle filtering updates an ensemble of fire trajectories to estimate spread probabilities and arrival-time uncertainty. We used RunPod CPU instances to precompute the Eaton wildfire replay across three observation scenarios.
For each map cell, the Rothermel model balances heat transferred into unburned fuel against the energy required for ignition:
$$ R_0=\frac{I_R\,\xi}{\rho_b\,\epsilon\,Q_{ig}}, \qquad R_h=R_0(1+\phi_{\mathrm{eff}}). $$
Reaction intensity \(I_R\) and propagating flux ratio \(\xi\) determine the available heat; bulk density \(\rho_b\), effective heating number \(\epsilon\), and preignition energy \(Q_{ig}\) determine the ignition requirement. Fuel moisture modulates combustion, while wind and slope accelerate and orient spread.
The perimeter emerges from these local physics. An elliptical spread law captures head, flank, and backing-fire motion. A level-set method advances the front through a Hamilton–Jacobi equation:
$$ \phi_t+H(\nabla\phi)=0, \qquad \phi^{n+1}=\min!\left(\phi^n,\phi^n-\Delta t\,\widehat H_{LF}\right). $$
The Lax–Friedrichs approximation stabilizes the numerical evolution, while the implicit perimeter representation handles merging fronts. Spread rates were checked against the U.S. Forest Service’s reference calculator.
Uncertainty is part of the computation. An ensemble of 50–100 simulations varies wind, fuel moisture, and ignition position. As satellite detections arrive, a particle filter reweights simulations by their agreement with observations. The weighted ensemble yields cell-level arrival-time quantiles at 10%, 30%, 50%, 70%, and 90%; each zone’s act-by time is its 30th-percentile arrival minus the time needed to evacuate.
Deep learning extension
To extend this physics-based foundation with deep learning, we designed a physics-assisted U-Net architecture to learn bounded spatial corrections to fire-spread rates, with PyTorch planned for training and ONNX for inference. The design preserves the physics solver’s role in propagating fire trajectories. Implementing, integrating, and validating this hybrid physics–deep learning model is our next step.
Frontend and story
We wanted the interface to feel like a mission-control room, not a spreadsheet. Our references were the glowing topographic maps of sci-fi command centers and the SpaceX look: dark, blue, and wide typefaces. The globe is drawn from scratch on a canvas. It zooms from the whole Earth to street level, with elevation contours from open terrain tiles and roads and landmarks from Census and USGS data.
The central idea in the interface is two sliders: one for actual time and one for the forecast from that moment out to six hours. Every five-minute step has its own forecast, so you can watch the fire's prediction move as the satellite looks again. Clicking any spot shows when the fire may reach it and how uncertain that is. A guided tour walks through the story, from the fire to the alert to the zone deadlines, in about a minute.
Challenges we ran into
For our demo on the Eaton fire, we weren't able to find any camera footage data due to the no-fly warning issued throughout the time of the crisis--thus, we weren't able to test out the camera data integration given the hackathon's time constraints. We also weren't able to build out full functionality to the level we wanted and focused on the backtested demo of the Eaton fire as a proof-of-concept due to time constraints.
Accomplishments that we're proud of
Getting a working physics-based machine learning model running within 36 hours and producing novel results towards solving a real, people and planet facing problem without compromising on user interface or having easily digestible results and understandable impact!
What we learned
- How wildfire spread is actually modeled, from fuels and wind to ensembles, and how to correct a model with noisy satellite pixels.
- How to build in parallel by agreeing on file formats first.
- What separates value from slop: a clear problem, real data, honest limits, and a demo that works.
What's next for Ember
So many ideas!
- implementing and evaluating our physics-assisted U-Net in PyTorch, exporting it to ONNX, and integrating learned spread-rate corrections into the Rust physics engine
- suggesting deployment maps for helicopters, firefighter units, and other firefighting methods
- full and seamless integration of many different types of natural disaster prediction
- fine-tuning our physics model for more accurate results and running tests on many, many more fires
- pitching our idea to VCs for potential funding
- victim-facing features for search & rescue operations
Built With
- amazon-web-services
- c++
- cartesia
- claude
- cursor
- geopandas
- github
- goes-18
- hrrr
- landfire
- maplibre-gl
- node.js
- numpy
- openrouter
- pydantic
- python
- react
- runpod
- rust
- scipy
- spacetimedb
- typescript
- usgs-3dep
- viirs
- vite

Log in or sign up for Devpost to join the conversation.