In November 2022, India Meteorological Department's medium-range forecasts were coming off Pratyush, the roughly 6.8-petaflop supercomputer split between IITM Pune and NCMRWF Noida — hours of computation across thousands of processor cores, solving a system of fluid-dynamics equations over the entire atmosphere, six times a day. A year later, DeepMind published GraphCast in Science: a neural network that produces a comparable 10-day global forecast — six atmospheric variables at 37 vertical levels, 0.25° resolution — in under a minute on a single Google TPU v4 chip, and that beat the world's leading physics-based forecast (ECMWF's HRES) on more than 90% of 1,380 tested variables. Same atmosphere, same target skill, four orders of magnitude difference in wall-clock time. What changed was not the physics of the atmosphere — it was the method used to model it.
This chapter is about that method: how weather and climate models have traditionally worked, why they cost so much to run, and the four distinct ways machine learning is now inserted into that pipeline — emulating the physics solver, sharpening coarse output into local detail, correcting systematic error against observations, and reading extreme events straight out of satellite imagery. It closes with where the substitution quietly breaks, because that failure mode is itself one of the more important ideas in the field right now.
What a physics-based model actually computes
A general circulation model (GCM) — the engine behind both weather forecasts and century-scale climate projections — is a numerical solution to a coupled set of partial differential equations called the primitive equations: conservation of momentum (Navier–Stokes on a rotating sphere, with the Coriolis force added), conservation of mass (the continuity equation), conservation of thermal energy, and conservation of moisture, closed by the ideal gas law relating pressure, density, and temperature. None of these have a closed-form solution for a real atmosphere, so the model does what any numerical PDE solver does: it lays a three-dimensional grid over the globe (longitude × latitude × height, typically tens of vertical levels), replaces each derivative with a finite-difference or spectral approximation using neighbouring grid values, and steps the whole state forward in small increments of time, re-evaluating every equation at every grid point at every step.
That last part — small increments — is not a design choice you can skip. It is forced by a stability requirement called the Courant–Friedrichs–Lewy (CFL) condition: information cannot be allowed to physically travel further than one grid cell in one time step, or the numerical scheme diverges. Formally, for grid spacing Δx and the fastest wave speed v present in the equations, stability requires
Δt ≤ C · Δx / v
where C is the Courant number (close to 1 for the schemes used operationally). This single inequality is the reason a finer grid is not just "more numbers to crunch" — it is disproportionately more numbers to crunch, and the next section derives exactly how much more.
The compute wall: why halving grid spacing costs 8×, not 2×
Take a horizontal grid spacing of Δx₁ = 100,000 m (100 km, a coarse global-model resolution) and a characteristic wave speed of v = 100 m/s (representative of the winds and gravity waves that limit the timestep in these schemes). With Courant number 1:
Δt₁ ≤ Δx₁ / v = 100,000 / 100 = 1,000 s (≈16.7 minutes)
Now halve the grid spacing to Δx₂ = 50,000 m to get finer detail:
Δt₂ ≤ Δx₂ / v = 50,000 / 100 = 500 s
The timestep had to halve too — that is what the CFL inequality forces. Consider a 6-hour forecast window, 21,600 seconds:
steps₁ = 21,600 / 1,000 = 21.6 → 22 steps
steps₂ = 21,600 / 500 = 43.2 → 43 steps (≈2× more steps)
Meanwhile, halving the spacing in both horizontal directions (longitude and latitude) quadruples the number of grid points covering the same area, since points scale as (Δx₁/Δx₂)² = (100/50)² = 4. Total computational cost is roughly grid points × timesteps, so:
cost multiplier = 4 (points) × 2 (timesteps) = 8×
Refine the vertical levels by the same factor too — common practice, since a model with fine horizontal grid but coarse vertical layers is unbalanced — and the multiplier climbs to roughly 16×. This is precisely why a factor-of-two jump in the headline "resolution" number of a weather model corresponds to needing a far-more-than-double supercomputer allocation, and why operational centres upgrade grid resolution only once every several years, not every year.
This is also the exact bottleneck that emulation-based AI models sidestep. GraphCast has no internal timestep and therefore no CFL condition to satisfy: it is a function that has learned to map an atmospheric state directly to the state six hours later in a single forward pass through a graph neural network. Doubling the output resolution changes the size of that one forward pass roughly linearly (more grid nodes to compute, once, per prediction) rather than multiplicatively through a stability-constrained timestep. The physics solver pays for resolution twice — once in grid points, once in forced-smaller timesteps. The neural emulator pays for it once.
Four places AI enters the pipeline
1. Emulation. This is what GraphCast and NVIDIA's FourCastNet do: replace the iterative PDE integration itself with a learned function trained on decades of past atmospheric states (typically the ERA5 reanalysis dataset). GraphCast represents the atmosphere as nodes on an icosahedral mesh — a near-uniform triangulated sphere, chosen because a plain latitude-longitude grid bunches grid points unrealistically near the poles — and uses a graph neural network to pass messages between neighbouring mesh nodes (encode the irregular input grid onto the mesh, process it through several rounds of message-passing that let information travel between distant nodes, decode back to the output grid). FourCastNet instead treats the atmosphere as a multi-channel image and uses a Fourier Neural Operator / vision-transformer-style architecture to learn the mapping in frequency space, which is well-suited to the wave-like structures atmospheric flow actually contains.
2. Downscaling. A global model's 25–100 km grid cannot represent a river basin, a city's rainfall gradient, or a coastline's wind funnelling — those features are smaller than one grid cell. Downscaling uses a convolutional network trained as an image super-resolution model: given a coarse field as input and a matching high-resolution field as the training target (from a regional model or dense station data), it learns to hallucinate plausible fine-scale structure consistent with local terrain and historical climatology. This is a fundamentally different task from emulation — emulation speeds up computing the same resolution faster; downscaling adds spatial detail that was never present in the coarse field to begin with. It is closer to learned, physically-constrained interpolation than to solving equations faster. This is the step that turns a coarse CMIP6-class global climate projection (100–250 km) into the roughly 4–12 km regional grids used in India's national climate change assessment work.
3. Bias correction and data assimilation. Every forecast starts from an estimate of today's atmospheric state, built by reconciling the previous forecast with millions of noisy, unevenly-spaced observations (satellite radiances, radiosondes, ships, buoys). This is itself an optimisation problem: the classical 4D-Var technique used operationally at ECMWF and India's NCMRWF finds the state x that minimises
J(x) = (x - x_b)ᵀ B⁻¹ (x - x_b) + (H(x) - y)ᵀ R⁻¹ (H(x) - y)
— a background term penalising drift from the prior forecast x_b, and an observation term penalising mismatch with the actual observations y (through an observation operator H), each weighted by an error-covariance matrix. Solved by gradient descent through the model's adjoint, this is the same "minimise a loss function" idea that trains a neural network — data assimilation has been doing it, at planetary scale, since the 1980s. Increasingly, machine learning is used either to learn better error-covariance estimates (B and R are hard to specify by hand) or, more aggressively, to learn the whole assimilation step end-to-end, and separately, ML models are trained to correct known systematic biases in physics-based output (a model that is reliably 1.5°C too warm over the Deccan Plateau in April, say) using historical forecast-versus-observation pairs.
4. Extreme-event detection. Convolutional networks trained for image classification and segmentation are applied directly to satellite imagery — for instance INSAT-3D data from ISRO — and to reanalysis fields, to automatically flag and track tropical cyclones, atmospheric rivers, and heatwave onsets, tasks historically done by trained analysts applying pattern-based rules (the Dvorak technique for estimating cyclone intensity from cloud-pattern imagery is the classic example now being partially automated with learned classifiers). This is a supervised computer-vision problem layered on top of climate data rather than a new kind of physics modelling.
The diagram below lays out how the first two of these — emulation and downscaling — fit together as an actual forecast pipeline, next to the physics-based path they are replacing or extending.
Worked example: an analog forecast, traced by hand
Before deep learning, the simplest data-driven forecasting idea was the analog method: find the historical day whose atmospheric state most closely resembles today's, and assume tomorrow will resemble what followed that historical day. It is a crude ancestor of today's learned emulators, but it is small enough to trace completely by hand, and doing so builds real intuition for the nearest-neighbour reasoning that sits underneath even much larger models. Suppose four historical days are described by two standardised anomaly features — sea-level pressure and 850 hPa temperature, both scaled to zero mean and unit variance across the historical record — together with the rainfall that followed each one at a station:
import math
history = [
{"x": 2.0, "y": 1.0, "rain": 5}, # Day A
{"x": -1.0, "y": 0.5, "rain": 40}, # Day B
{"x": 0.5, "y": -1.5, "rain": 60}, # Day C
{"x": 1.8, "y": 0.9, "rain": 8}, # Day D
]
today = {"x": 1.9, "y": 1.0}
def distance(a, b):
return math.sqrt((a["x"] - b["x"]) ** 2 + (a["y"] - b["y"]) ** 2)
ranked = sorted(history, key=lambda d: distance(d, today))
for day in ranked:
print(round(distance(day, today), 4), day["rain"])
k = 2
neighbours = ranked[:k]
weights = [1 / distance(n, today) for n in neighbours]
forecast = sum(w * n["rain"] for w, n in zip(weights, neighbours)) / sum(weights)
print(round(forecast, 2))
Trace it by hand before reading on. Day A: √((2.0-1.9)² + (1.0-1.0)²) = √0.01 = 0.1. Day D: √((1.8-1.9)² + (0.9-1.0)²) = √0.02 ≈ 0.1414. Day C: √((0.5-1.9)² + (-1.5-1.0)²) = √8.21 ≈ 2.8653. Day B: √((-1.0-1.9)² + (0.5-1.0)²) = √8.66 ≈ 2.9439. So the loop prints:
0.1 5
0.1414 8
2.8653 60
2.9439 40
The two nearest neighbours are Day A (distance 0.1, rain 5 mm) and Day D (distance 0.1414, rain 8 mm). Inverse-distance weights are w_A = 1/0.1 = 10 and w_D = 1/0.1414 ≈ 7.0711. The weighted forecast is (10×5 + 7.0711×8) / (10 + 7.0711) = 106.5685 / 17.0711 ≈ 6.24, so the final printed line is 6.24 — a forecast pulled slightly above Day A's 5 mm because Day D, also very close, points a little higher. Two things generalise from this toy example to real emulators: first, everything reduces to a distance in some learned feature space and a weighted read-out of what happened after similar past states; second, the forecast is only as good as the historical record's coverage of the situation at hand — a genuinely novel atmospheric configuration has no good analog, which is exactly the situation deep-learning emulators handle better, because they interpolate a learned continuous function rather than only ever looking up literal historical days.
The misconception: "if it beats physics on weather, it can replace physics on climate"
Having seen GraphCast out-forecast a physics-based model, it's a natural jump to assume a large enough neural network could simply replace physics-based climate models altogether, for century-scale projections and not just 10-day forecasts. This conflates two different problems. Weather forecasting is an initial-value problem over a short, bounded horizon: predictability is fundamentally limited to a couple of weeks by the chaotic growth of small errors (the same sensitivity Edward Lorenz demonstrated with his toy convection model), so a forecasting emulator only needs to stay accurate through a few dozen autoregressive 6-hour steps before its errors would have swamped even a perfect physics model anyway. Climate projection is a different kind of problem — closer to a boundary-value / statistical-equilibrium problem: it asks how the long-run statistics of the system (average temperature, rainfall distribution) respond to a changed boundary condition (rising CO₂) over thousands of autoregressive steps, decades to centuries long. A pure data-driven model trained only to minimise next-step error has no guarantee of conserving energy or mass over that many rollout steps; small, statistically negligible per-step errors compound, and without a hard physical constraint the trajectory can drift into unphysical states — for instance a slow, spurious global energy imbalance that a real atmosphere could never sustain. This is precisely why the current state of the art for climate-length AI modelling, such as Google's NeuralGCM (Kochkov et al., published in Nature in 2024), is a hybrid: it keeps a differentiable, physics-based dynamical core — which guarantees the conservation laws are respected by construction — and uses a neural network only for the sub-grid processes (cloud formation, convection) that physics-only climate models have always had to approximate crudely because they happen at scales smaller than any affordable grid can resolve. The correction to hold onto: AI is currently winning decisively on short-horizon weather emulation, and is being folded carefully, as one physically-constrained component, into long-horizon climate modelling — not swapped in wholesale for either.
Active recall
Attempt each question before reading its answer.
- A weather centre doubles horizontal resolution from 50 km to 25 km grid spacing, keeping vertical levels fixed. Using the CFL condition, by what factor does the cost of one forecast (grid points × timesteps) increase? Show the arithmetic.
- In one sentence, explain why GraphCast's runtime does not depend on the CFL condition the way a physics-based solver's does.
- In the analog-forecast code, what would the forecast be with
k = 1instead ofk = 2, and why does it differ from thek = 2answer of 6.24 mm? - GraphCast never solves the Navier–Stokes equations directly. Explain how physics still enters its training, and what it is validated against.
- Give one concrete reason a network trained only to predict "state at t+6h given state at t" is a poor direct choice for a 100-year climate projection, and name one architecture built to fix it.
- A flood-forecasting team has global model output at 25 km resolution but needs 1 km river-basin detail. Which AI technique fits, and how is that problem fundamentally different from emulation?
Answers.
1. Grid points scale as (50/25)² = 4× since halving spacing in two horizontal directions quadruples the points covering the same area. The CFL condition forces the timestep to halve too, doubling the number of steps needed to cover a fixed forecast window: 2×. Total cost multiplier: 4 × 2 = 8×.
2. GraphCast does not numerically integrate the PDEs through many small stability-constrained steps — it is a single learned function mapping state(t) directly to state(t+6h), so there is no internal timestep whose stability depends on grid spacing and wave speed.
3. With k = 1 the forecast is just Day A's rainfall, 5 mm — the single nearest neighbour. The k = 2 answer of 6.24 mm is higher because it blends in Day D's 8 mm, weighted by inverse distance, since Day D (distance 0.1414) is almost as close as Day A (distance 0.1).
4. GraphCast is trained on the ERA5 reanalysis dataset, which is itself produced by a physics-based forecast model combined with real observations through 4D-Var data assimilation. Physics therefore enters indirectly, through the training targets, rather than being computed inside the network. It is validated by comparing its forecasts to held-out reanalysis and direct observations.
5. Autoregressive next-step errors compound over thousands of rollout steps, and without a hard conservation constraint the trajectory can drift into unphysical states (for example, a spurious long-run energy imbalance). NeuralGCM (or any hybrid physics-core-plus-learned-parameterisation architecture) is built to fix this by keeping a differentiable physics-based dynamical core that guarantees conservation, using the neural network only for sub-grid processes.
6. Downscaling (CNN-based statistical super-resolution) is the right technique. It differs from emulation because emulation speeds up computing the same resolution's dynamics faster; downscaling has to add spatial detail — terrain-driven rainfall gradients, coastline effects — that simply is not present in the coarse 25 km field at all, so it is closer to physically-constrained learned interpolation than to solving the dynamics equations more efficiently.
Think About It
Think about this: How would you explain climate modeling and environmental ai to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.
Key Takeaways — Summary and Recap
Let us recap what we covered: the core ideas behind climate modeling and environmental ai, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.