Grid-Stat

Compare a gridded forecast against a gridded analysis — cell by cell, and neighborhood by neighborhood.

Grid-Stat scores a gridded forecast field against a gridded observation or analysis field on a common grid. It works much like Point-Stat, but instead of matching forecasts to scattered observation points, it forms one matched pair at every grid cell. On top of the usual continuous, categorical, and probabilistic measures, it adds neighborhood (spatial / “fuzzy”) verification — the family of methods that give a forecast credit for being close rather than demanding a pixel-perfect hit.

What Grid-Stat is

In the MET sense, verification means measuring how well a forecast matched what actually happened. Grid-Stat is the MET tool for the case where both sides are gridded: a model forecast field (for example, 24-hour accumulated precipitation) and a gridded “truth” field — an analysis, a radar/satellite product, or another gridded observation set. The documentation puts it plainly: Grid-Stat “functions in much the same way as the Point-Stat tool, except that the verification statistics it calculates are for a matched forecast-observation grid (as opposed to a set of observation points).”

Where Point-Stat answers “how good is the forecast at the places we observed?”, Grid-Stat answers “how good is the whole field?” — every grid cell becomes a matched pair, so the score reflects the spatial structure of the forecast, not just a handful of sample sites.

Grid-Stat groups its measures into a few families:

Continuous

For continuous variables (temperature, pressure, accumulated precip read as a number) — error magnitude and the relationship between forecast and observation, plus the partial sums used to aggregate them.

Categorical

Apply a threshold to turn the field into yes/no events, then tally a contingency table — a 2×2 count of hits, misses, false alarms, and correct negatives (and a multi-category version for fields split into more than two bins).

Probabilistic

For probability forecasts (values in 0–1 or 0–100) — reliability (do 30%-forecasts verify 30% of the time?), resolution, and overall skill.

Neighborhood & spatial

The “fuzzy” methods — fractional coverage, the Fractions Skill Score, and distance maps. This is what sets Grid-Stat apart from a strict cell-for-cell score.

The exact line-type codes for each family (CNT, FHO, CTC, CTS, NBRCNT, and the rest) are listed in the output line types table below.

Climatology is optional: if you supply a gridded climatological field — a long-term average baseline of what is “normal” — “on the same grid as the forecasts and observations,” Grid-Stat can also score anomalies (departures from that baseline) and report skill relative to simply predicting the climatological normal.

Inputs & regridding

Grid-Stat needs three things: a gridded forecast file, a gridded observation file (analysis or gridded obs), and a configuration file. Forecast and observation inputs may be GRIB, NetCDF, or other MET-supported gridded formats.

The two fields do not have to start on the same grid. As the docs state, “neither the forecast nor the observation grid needs to be identical to the final matched grid.” When the grids differ, Grid-Stat regrids (interpolates) each field onto a common verification grid before scoring. You choose that destination grid with the regrid dictionary in the config.

Why regrid first

Every statistic Grid-Stat reports assumes forecast cell i and observation cell i describe the same patch of the atmosphere. Regridding both fields to one grid is what makes that true — get it right and the matched pairs are meaningful; skip it and the scores are comparing apples to a different map projection.

How matching works

On the common grid, Grid-Stat lays the forecast field over the observation field and reads off a matched pair at each cell. For categorical and neighborhood scores, a threshold first converts each field into a binary event mask (event / non-event). The neighborhood inset below shows the second idea: a moving window scans the grid and, at each center cell, computes the fractional coverage — the share of cells inside the window that exceed the threshold.

Figure 1. Left: forecast and observation fields are co-registered on a common grid, forming one matched pair per cell. Right: a square neighborhood window slides across the event mask; at each center it counts how many cells exceed the threshold, giving the fractional coverage that feeds neighborhood scores such as the Fractions Skill Score. The inset uses a small 3×3 window (5 of 9 cells = 5/9); the worked example under Fractional coverage below uses a 5×5 window (10 of 25 = 0.4).

The double-penalty problem

Pixel-for-pixel scoring has a famous failure mode. Suppose a high-resolution model forecasts a sharp rain cell in exactly the right shape and intensity, but a few grid cells too far east. Traditional grid-point matching scores this twice as wrong: it counts a false alarm where the forecast put rain and a miss where the rain actually fell. A blurry, low-amplitude forecast that smears rain everywhere often beats the sharp, nearly-right one. That perverse outcome is the double-penalty problem.

Why neighborhood scores help

Neighborhood methods stop demanding a strict cell-for-cell match. As the docs describe them, they “compare the forecasts and observations in a neighborhood surrounding the point of interest” instead of comparing a single forecast point to a single observation point. A forecast that is close — right shape, slightly displaced — earns credit. This rewards sharp, realistic fields and removes the incentive to over-smooth, which is exactly the bias a single-cell score introduces.

Neighborhood verification

This is Grid-Stat’s signature capability. The user defines “a square search window around each grid point. Within the search window, the number of observed events is compared to the number of forecast events.” The method gives “credit to forecasts that are close to the observations without requiring a strict match between forecasted events and observed events.”

Fractional coverage

For each grid point, Grid-Stat computes the fractional coverage: “the proportion of forecast points in the neighborhood that exceed the forecast threshold.” The documentation’s own example: “if 10 of the 25 forecast grid points contain values larger than a threshold of 2, then the coverage is 10/25 = 0.4.” The same is done for the observation field, producing a forecast fraction and an observation fraction at every cell.

Fractions Skill Score (FSS)

The headline neighborhood metric. FSS compares the forecast and observation fractional-coverage fields, rewarding agreement in how much of each neighborhood is “on” rather than exactly which cells. Its companion, the Fractions Brier Score (FBS), is the underlying squared-difference term. Both are reported in the NBRCNT line type. FSS is bounded such that a perfect forecast scores 1; a score that improves as the neighborhood grows tells you the spatial scale at which the forecast becomes skillful.

Neighborhood contingency tables

Grid-Stat also recasts the classic 2×2 contingency table in neighborhood terms by applying a coverage threshold to the fraction fields, producing NBRCTC (counts) and NBRCTS (the derived statistics). To use these you specify, per the docs, the neighborhood window size, the required fraction of valid data within the window, and the fractional-coverage threshold.

The three knobs of a neighborhood score

(1) window size — how large a patch counts as “close”; (2) valid-data fraction — how much of the window must contain good data for the cell to count; (3) coverage threshold — how much of the window must be “on” to call the neighborhood an event. Sweep the window size to see at what scale the forecast earns skill.

Beyond neighborhoods: distance maps & gradients

Grid-Stat carries two more spatial families. Distance-map statistics (DMAP) are computed on binary event fields and include Baddeley’s Δ metric, Hausdorff distance, mean-error distance, Pratt’s Figure of Merit, Zhu’s measure, and the G_β measure — all ways of quantifying how far apart the forecast and observed event regions are. Gradient statistics (GRAD) evaluate “differences between adjacent grid points in forecast and observed fields,” reporting the S1 score and gradient-magnitude measures that assess field texture independent of bias.

Configuration highlights

Grid-Stat is driven by a text config file. A few dictionaries do most of the work:

regrid — Defines the common grid on which scores are computed, and the interpolation used to get the forecast and observation fields onto it.

cat_thresh (thresholds) — Sets the event thresholds for categorical and neighborhood scoring. Thresholds use Fortran-style operators <, <=, ==, !=, >=, > (or two-letter forms lt, le, eq, ne, ge, gt). Complex events combine simple thresholds with && and ||, and may be unioned or intersected (UNION / INTERSECTION / SYMDIFF).

mask — Restricts scoring to verification regions — e.g. grid definitions and polygon files (mask = { grid = [ "FULL" ]; poly = []; }). Statistics are reported per masking region.

interp — Controls smoothing / interpolation applied to the fields before verification — method, width, and shape.

nbrhd — The neighborhood dictionary: shape (SQUARE or CIRCLE), width (an odd integer), coverage thresholds, and validity thresholds — the controls behind NBRCTC, NBRCTS, and NBRCNT.

nc_pairs_flag — Toggles the optional NetCDF matched-pairs output containing forecast, observation, and difference fields.

Output line types

Grid-Stat writes a combined .stat file plus, optionally, one ASCII .txt file per line type. The format matches Point-Stat’s output, with the additional spatial line types unique to Grid-Stat. Each row is tagged with a line-type code:

Line type	Family	What it reports
FHO	Categorical	Forecast, Hit, Observation rates
CTC	Categorical	2×2 contingency table counts
CTS	Categorical	Contingency table statistics derived from CTC — e.g. POD (probability of detection), FAR (false alarm ratio), CSI (critical success index), and HSS (Heidke skill score)
MCTC	Categorical	Multi-category contingency table counts
MCTS	Categorical	Multi-category contingency table statistics
CNT	Continuous	Continuous statistics (error, correlation, etc.)
SL1L2	Continuous	Scalar partial sums (L1L2)
SAL1L2	Continuous	Scalar anomaly partial sums (climatology supplied)
VL1L2	Vector	Vector partial sums (e.g. wind components)
VAL1L2	Vector	Vector anomaly partial sums (climatology supplied)
VCNT	Vector	Vector continuous statistics
PCT	Probabilistic	Contingency table counts for probability forecasts
PSTD	Probabilistic	Contingency table statistics for probability forecasts
PJC	Probabilistic	Joint and conditional factorization
PRC	Probabilistic	ROC (Receiver Operating Characteristic) data
ECLV	Value	Cost/loss ratio relative value
NBRCTC	Neighborhood	Neighborhood contingency table counts
NBRCTS	Neighborhood	Neighborhood contingency table statistics
NBRCNT	Neighborhood	Neighborhood continuous stats — incl. FSS & FBS
GRAD	Spatial	Gradient statistics (S1 score, gradient magnitudes)
DMAP	Spatial	Distance-map statistics (Baddeley Δ, Hausdorff, Gβ, …)
SEEPS	Categorical	Stable Equitable Error in Probability Space score

Reading the family column

Pick the line type that matches your question. Continuous error? CNT. Threshold-exceedance hits and misses? CTC/CTS. Is the forecast skillful at some spatial scale even if displaced? NBRCNT (FSS). How far off is the event region geometrically? DMAP.

Running Grid-Stat

Grid-Stat is a command-line tool. The three required arguments are the forecast file, the observation file, and the config file:

grid_stat sample_fcst.grb sample_obs.grb GridStatConfig

1. Prepare the two gridded fields. A gridded forecast file and a gridded observation/analysis file (GRIB, NetCDF, or other MET-supported formats). If a climatology is used, it must be on the same grid as the forecasts and observations.

2. Write the config. Set the field(s) to verify, the regrid destination grid, cat_thresh event thresholds, mask regions, interp smoothing, and the nbrhd dictionary if you want neighborhood scores. Enable nc_pairs_flag for the optional matched-pairs NetCDF.

3. Run the tool. Optional flags include -outdir (output directory), -log (log file), -v (verbosity; default 2), and -compress (NetCDF deflate level). A separate -ugrid_config file supplies UGRID metadata when needed.

4. Read the output. A combined STAT file named like grid_stat_PREFIX_HHMMSSL_YYYYMMDD_HHMMSSV.stat, optional per-line-type ..._TYPE.txt files (fho, ctc, …, nbrcnt, grad, dmap), and an optional ..._pairs.nc with forecast, observation, and difference fields per masking region.

Vectors & probabilities

Wind verification is supported, including direction with a minimum-speed condition so that direction is not computed at near-calm speeds. Probability forecasts are accepted in 0–1 or 0–100 ranges, with bins defined so that each threshold applies on its lower bound.

Downstream

Grid-Stat’s STAT output is a stepping stone, not the end. Because its format matches Point-Stat’s, the same aggregation machinery applies.

Ecosystem link

The STAT files from grid_stat feed directly into Stat-Analysis for filtering, stratification, and aggregation across many runs. The resulting statistics — and the matched pairs — are visualized with METplotpy and explored interactively in METviewer. The whole sequence is typically orchestrated by METplus wrappers.

For the object-based counterpart — where instead of cell-by-cell or neighborhood scoring you identify coherent forecast and observed features and match them — continue to MODE.

---

A derived, human-readable re-presentation — not official documentation. Sources: MET User’s Guide — Grid-Stat Tool