About FrankenNAM
The NAM’s own model code, run on cloud hardware, started from the GFS instead of the NAM’s data assimilation.
A forecast cycle is called C below: the cycle time, 00Z or 12Z.
The design
- The NAM's own code. NMMB/NEMS (the dynamical core and model), NPS (the preprocessor) and UPP (the post-processor), built from the operational NAM v4.2 source. Run on AWS Graviton (arm64) Spot instances; the port needed a small set of source patches, all kept in the repository.
- Same grid and physics. The full 12 km North American parent domain (954×835, 60 levels, 25 s time step), Ferrier-Aligo microphysics, BMJ convection, MYJ boundary layer, Noah land surface, RRTM radiation. Output is regridded to grid 218 and written as
awphysfiles that match the operational file inventory record for record (454 records at f24). - Free maps and free files. The maps are free. The GRIB2 files for the re-run cases are free too, on the Grids page. What it took to run them is on the Costs page.
How a FrankenNAM run starts
A product cycle C is a 90 h integration that starts at C−6 h. The initial condition is the GFS analysis for that time, the lateral boundaries are the GFS forecasts that follow, and the first 6 h are a NAM spin-up. Integration hour 6 is forecast hour 0 of the product, and hour 90 is f84. That f00 is what FrankenNAM calls its analysis, in the same way the operational NAM’s 6 h catch-up ended in its analysis; it comes from the model alone, not from observations. Because the run starts 6 h early, the first day of forecast can be ready before the cycle time itself.
The soil (moisture, temperature, snow water) is seeded from the NAM’s own land state rather than the GFS’s, because the GFS soil is about 0.05 m3/m3 wetter than the NAM’s over the lower 48. On the 2026-11-01 case, FrankenNAM’s soil moisture at f00 is within 0.02 m3/m3 of the NAM’s. The run also includes our patch (nps-02) for a bug in NOAA’s nemsinterp that started every run with unfrozen soil; with it, 2 m temperature stays close to the NAM’s.
? what is seeded and what is not
Strategies we tried
There is more than one way to bring the NAM back. Each one below is a choice about the starting state, the chips or the code. The numbers are on the Validation page or in the repository’s docs/. (a), (e) and (f) come from the 2026-11-01 case only.
(a) Start from the GFS analysis at C: the cold start
The simplest start: take the GFS analysis valid at the cycle time and run the NAM from it. Its f00 is the GFS analysis, which is clean, but the NAM’s boundary layer and land state have had no time to settle, and its soil is the GFS’s. On the 2026-11-01 case it was slightly closer to the NAM than the chosen start at f24 for sea-level pressure, and further away by f84. We did not keep it.
(b) Start 6 h early with a NAM spin-up: chosen
Described above. Forecast hour 0 is the model’s own state, not the GFS’s, and it stays far closer to the archived NAM than the GFS does (Validation). The cost is that it knows nothing after the start time, and its 2 m temperature at f00 is a little warm, which is gone by f12.
(c) Seed the NAM’s land state: chosen
Described above: the NAM’s soil moisture, soil temperature and snow instead of the GFS’s.
(d) x86 against Graviton
The same model, built for AWS Graviton (arm64) as well as x86. An 84 h run cost $2.33 on a Graviton Spot node against $3.81 on x86 (39 % less). Graviton was 6 % slower per forecast hour (200 against 189 s) in single runs on different node classes. The fields differ from the x86 run by roundoff that grows to a few tenths of a kelvin or less by f84, the ordinary sensitivity of a weather model to rounding. Details are on Costs.
(e) WOOF-NAM’s GPU rewrite
WOOF-NAM, from Recast Systems, rewrites the NMMB dynamics and NAM physics for NVIDIA GPUs, in single precision. Its grids are currently free, and that matters: it is the simplest way to get a NAM-like forecast every day. We ran it once ourselves on 2026-11-01 00Z with FrankenNAM’s 6 h-early start, but its own soil (the GFS’s) and boundaries (the GFS run 6 h older). It took 59 minutes on one GPU, and on that case it was the closest to the archived NAM at f84.
(f) WOOF-NAM behind our pipeline, with our seed
We built it once: WOOF-NAM’s engine, our 6 h-early start, our NAM soil seed, and our product writer. It ran in 54 minutes from boot to the last file and, on the same case, was closer to the NAM at f84 than the CPU run. The files match the CPU files record for record except for the records WOOF-NAM does not write, among them 12 h snowfall and the precipitation-type flags. For snow and ice that is the whole point of the NAM, so this path is backlogged until those exist.
What a live cycle would take
FrankenNAM does not run on a schedule, and this is not a service promise. It is what a live 12Z cycle would take, as measured and projected. Measured on the acceptance run (one 32-core Graviton node): 193 s per forecast hour, and the last product file lands 85 s after the model ends. Projected for one such node, launched when the 06Z GFS is on AWS:
The pace is measured; the launch time and the clock are projected, because no live cycle has run. A larger node may close the 23 minute gap; that is not yet measured.
FrankenNAM, the operational NAM and WOOF-NAM
WOOF-NAM is another project bringing the NAM back, from a different direction: it rewrites the model for GPUs, where FrankenNAM runs the NAM’s own code. The WOOF-NAM column is as of 5 November 2026, from its public repository and demo feed.
| FrankenNAM | Operational NAM (retired 3 Nov 2026) | WOOF-NAM | |
|---|---|---|---|
| Code | NMMB/NEMS, NPS, UPP from the operational NAM v4.2 source, built for Graviton (arm64); no GSI | The same, plus GSI and the NDAS cycling scripts, on WCOSS2 | A new GPU (CUDA) version of the NMMB dynamics and NAM physics, written from the same NAM source; single precision, not bit-for-bit |
| Grid, levels, time step | 954×835 rotated lat-lon B grid, 12 km, 60 levels, 25 s | The same | The same |
| Physics | Ferrier-Aligo, BMJ, MYJ, Noah, RRTM | The same | The same schemes, rewritten; WRF land-surface tables stand in for the NAM’s |
| Initial conditions | GFS analysis at C−6 h, then 6 h of NAM spin-up (TDFI at the start) | NDAS: a 6 h catch-up cycle of analyses and short forecasts | GFS analysis at C, no spin-up (the archived NAM analysis or ECMWF open data are also options in the tool) |
| Data assimilation | None. No observations after C−6 h | GSI hybrid 3DEnVar every hour of the catch-up; radar, satellite, aircraft, surface and other observations | None |
| Land state | Seeded from the NAM’s land state (the archived NAM’s at the start of a case); canopy water zero | Cycled continuously | Taken from the starting analysis (the GFS’s soil for a live run) |
| Lateral boundaries | GFS forecasts, f006 to f090 of the C−6 cycle | GFS | GFS forecasts from the cycle 6 h older |
| Nests | None: the 12 km parent only | 3 km CONUS and Alaska, Hawaii, Puerto Rico and fire-weather nests, to 60 h | None: the 12 km parent only |
| Cycles | Occasional: notable events, run on demand and added as cases (each case is a 00Z or 12Z cycle) | 4 a day (00Z, 06Z, 12Z, 18Z) | 4 a day in its public demo feed |
| Products, file names | awphys on grid 218 (614×428, 12.19 km), f00–f84 every 3 h, with the operational names (nam.tCCz.awphysFF.tm00.grib2); the grids are free for the re-run cases | The same names; more products and hours (hourly output, other grids, BUFR soundings) | Grid 218 GRIB2, f00–f84 hourly, named woof-nam.tCCz.awphysFF.tm00.grib2; free in a demo feed with 7-day retention; the run-it-yourself tool writes NetCDF |
| Delivery time of f84 | C+3:05 projected on one node, if run live | C+2:42 | About C+4:20 observed in the demo feed, on a GPU |
| Who runs it | A community project (Joe Boomgard-Zagrodnik), on rented cloud computers | NOAA/NCEP Central Operations | Recast Systems; open source (Apache-2.0), also runs on your own NVIDIA GPU |
How it came back
NCEP announced in September 2026 that the NAM source would be removed on retirement and available only on request. When NCEP's own copy came down, the NAM developers' public GitHub repositories (the model source and the Rocoto workflow) supplied what was needed. The static files the model reads at run time (terrain, land-use and soil tables, CO2) were recovered from Wayback Machine captures of earlier NAM v4.2 releases.
What could not come back is the NAM's data assimilation: its analysis needs an 80-member ensemble that was never public and would be too costly to replicate.
Sources: the project's scoping and build notes, and the design notes for the analysis, in the repository. FrankenNAM does not speak for WOOF-NAM or any other NAM recast.