PyRe — Frequently Asked Questions

Data sources, methods, and scientific design decisions organized from foundational concepts to more technical detail.

1. What is PyRe?

PyRe is an independently built replacement for the NOAA/PSL interactive reanalysis composite pages that stopped updating in March 2026 when the underlying NCEP Reanalysis dataset was discontinued. PSL has no plans to rebuild the interface for the successor dataset. PyRe replicates the three PSL interfaces:

• Monthly/Seasonal Composites — composite means over one or more calendar months
• Daily Mean Composites — one or more calendar days, each the archive's daily mean of all eight analyses
• 3-Hourly Composites — a single analysis time (00/03/06/09/12/15/18/21z) or averaged across a date list

2. What happened to the old PSL reanalysis pages?

The PSL composite tools were built on NCEP Reanalysis 1 (R1), a global retrospective analysis that ran from 1948 through March 2026. When NCEP discontinued R1 as the operational product and replaced it with CORe (Climate-Ocean Reanalysis), the PSL interface was not updated. PSL's existing pages are archived but show no data after March 2026.

3. What data does PyRe use for observations (the actual maps)?

PyRe uses CORe — Climate-Ocean Reanalysis from NCEP/CPC.

• Resolution: 0.703° × 0.703° (~78 km at mid-latitudes), the T170 gaussian grid — about 3.5× finer than R1 in each direction, or roughly 13× smaller grid boxes by area
• Temporal coverage: January 1, 1950 to near-real-time
• Format: GRIB2 ensemble mean files; PyRe fetches data surgically using HTTP byte-range requests (no full file downloads)
• Naming: pgb.{YYYYMMDD}{HH}.grb (pressure levels) and flx.{YYYYMMDD}{HH}.grb (surface) in the GCS archive; core.t{HH}z.spgb.ensmean.anl.grib2 on NOMADS for the most recent week

CORe is the designated successor to R1/R2 for NCEP operational reanalysis products.

4. Can I use R2 (NCEP Reanalysis 2) for the actual map data?

No. In PyRe, R2 is used exclusively for the climatological baseline — the 30-year mean and standard deviation used to compute anomaly and normalized anomaly maps. R2 is never used as the source for the observation fields shown on raw or composite maps.

Why not? R2 stopped updating in early 2026 and has no near-real-time data. Its 2.5° spatial resolution is also significantly coarser than CORe's 0.703°. For any map showing what the atmosphere looked like on a specific date, CORe is the correct source.

5. So what IS R2 used for, and why?

R2 is an alternative climatology baseline, the reference an anomaly is measured against. The default baseline on every time scale is CORe's own normals (see Q29). R2 stays available for one reason: a lot of published work used PSL's R1 and R2 normals, and someone reproducing a figure from that work needs the same baseline. The gear on the Analysis card switches a map to the R2 family: R2 monthly normals for monthly maps, R2 daily normals for daily maps, and R1's per-hour means for 3-hourly maps of fields with a daily cycle. The map's second subheader line names whichever normal was used.

Thirty variables have no R2 or R1 file at all (cloud layers, most radiation fields, CAPE and CIN, the lifted indices, and others). For those the panel offers CORe only.

6. What variables are available?

Pressure-level variables (16 standard levels: 1000, 925, 850, 700, 600, 500, 400, 300, 250, 200, 150, 100, 70, 50, 20, 10 mb unless noted):

Surface and single-level variables:

"Raw maps only" means no climatology/anomaly modes are wired yet — either R2 has no matching baseline file, or the derivation is deferred (see climo_sources in backend/app/config.py).

7. What map modes are available?

Anomaly and normalized anomaly maps require a climatology source.

How anomaly maps are built by time scale

Anomaly is observation minus normal. Normalized anomaly divides that by the normal's standard deviation, so the map reads in standard deviations. Climatology is not an anomaly: it shows the normal for the chosen period.

Q29 explains how each normal is built. Precipitation total has no normal (a window total has no monthly form), so it is raw only.

Precipitation, cloud cover, and radiation fluxes come from CORe forecast-background fields. They are useful for broad case-study context, but they are not gauge or radar precipitation totals, station sky-condition reports, or pyranometer measurements.

8. Why does a 3-hourly map use a different baseline than a daily map?

Because a single hour has to be compared against that same hour, not against the whole day.

Afternoons are warmer than the daily average and nights are colder. That is true on a completely ordinary day. So if a 2 p.m. reading is compared against the average of the whole 24 hours, it looks warmer than normal even when nothing unusual is happening, and a 5 a.m. reading looks colder.

On a map this is worse than a simple offset. One map covers many time zones at once, so the size of the error changes across the map, and it is near zero over the ocean, which barely warms or cools between day and night. The result looks like a weather pattern but is really a picture of the clock.

Measured on a quiet day (May 4, 1986, CONUS 2m temperature), the average anomaly across the map swung 5.5°F between hours when compared against a daily average. Against per-hour normals, that swing dropped to 2.0°F, and the warm-afternoon, cold-night pattern disappeared.

Only fields with a daily cycle get the hourly normal. Omega, vorticity, precipitable water, and the stratus cloud layers are set by weather systems, not by the clock: the values through a day are nearly the same number, so their daily normal already is the normal for any hour, measured with fifteen times the samples. Those fields use the daily normal at every time scale. The fields that do change with the clock, and so get an hourly normal for 3-hourly maps, are temperature, relative humidity, specific humidity, height, and wind speed on every pressure level, 2 m temperature, dewpoint, and humidity, 10 m wind, mean sea level pressure (a small twice-daily tide), all the radiation fields, CAPE and CIN, the lifted indices, storm-relative helicity, wind gust, and convective cloud cover.

Why the upper-air fields are on that list, at every level. Until September 17, 2026 pressure-level temperature, humidity, and height used the daily normal, on the reasoning that the air away from the ground has no daily cycle. Measured, that holds only part of the way. The table is the hourly normal (00Z, late afternoon in the West) minus the daily normal over CONUS, which is exactly the error a daily normal puts into a 00Z anomaly map: the largest value on the map, then the value that 95 % of the map stays under.

Over the high terrain of the West the 925 and 850 mb surfaces sit at or below the ground, so they warm and dry through the afternoon almost as much as the 2 m air does. Relative humidity carries a daily cycle far higher: the summer afternoon storms over the Rockies and the Sierra Madre moisten the column to 200 mb at the same hour every day. Specific humidity differs by up to 3 g/kg at 1000 mb, and height by 1 to 4 dam at every level in both seasons (the daily pressure tide). Wind speed differs by 5 to 8 kt at 925 and 850 mb, most under the Great Plains low-level jet in the hours before dawn, and by about 3 kt aloft. About 0.5 to 1 kt of that, at every level, is not a daily cycle but arithmetic: the speed of a day's average wind is lower than the average of its eight speeds, because a wind that changes direction through the day partly cancels when it is averaged. The hourly normal removes that as well. Omega differs by under 0.1 Pa/s outside a few mountain points and stays on the daily normal.

Temperature alone could have stopped at 850 mb, and winter humidity at 700 mb. PyRe uses one rule instead of a level or a season breakpoint: where a level has no daily cycle the two normals agree to within the noise (0.1 °C above 600 mb), so the hourly normal is never the worse choice, and maps of neighboring levels and of different seasons stay comparable. It is also the right spread for a normalized map: one analysis varies more than a daily mean does, so the hourly sigma is the one a single hour should be divided by. The measurement is two dates at one hour over one region; it sets which fields have a daily cycle, not its exact size everywhere.

Where the per-hour normals come from. CORe's own 3-hourly archive: for a given calendar day and hour, the analyses at that hour over the 30 base years, pooled over a 15-day window (Q29). Every one of the eight hours is read directly; nothing is interpolated. On the R2 baseline the per-hour normal is PSL's R1 4×-daily long-term mean instead, published for 00/06/12/18z and blended for the hours between; those files carry no standard deviation, which is why a normalized 3-hourly map of a diurnal field is not available on the R2 baseline.

WPC describes this kind of standardized anomaly as a daily climatology with a centered 15-day average, then (field - mean) / sigma: https://www.wpc.ncep.noaa.gov/training/prod_gen.html. PSL's NCEP atlas notes that standard deviation can be defined differently depending on the product, so PyRe labels the baseline on the map: https://psl.noaa.gov/data/ncep_reanalysis/procedures.html.

9. How are wind anomalies defined?

PyRe treats wind anomalies as vector departures from climatology:

• Compute component anomalies U' = U_obs − U_climo and V' = V_obs − V_climo
• Compute the magnitude of the anomaly vector as |V'| = sqrt(U'² + V'²)

The shaded field is positive-definite. It does not indicate stronger vs weaker than normal in a signed scalar sense; instead it measures the size of the departure from the climatological flow vector. When vectors or barbs are enabled on this map, they show the anomaly components (U', V'), not the actual observed wind.

Use this when the main question is circulation: monsoon onset, cross-equatorial flow, directional shifts, displaced jets, anomalous inflow, or broad pattern changes.

For example, if the climatological 850 mb wind is weak easterly and the observed wind is strong southwesterly, the wind anomaly emphasizes the anomalous southwesterly flow rather than only asking whether the wind speed was faster or slower than normal.

10. How is the standard deviation (sigma) calculated?

PyRe computes every sigma itself; no source publishes one at the resolution PyRe needs.

• Monthly normal: the sample standard deviation of the 30 individual monthly means for that calendar month, 1991–2020.
• Daily normal: the sample standard deviation of the pooled window: the 15 calendar days centered on the day, in each of the 30 years, 450 values at every grid point.
• Hourly normal: the same pool, at that hour only.

Sample standard deviation means dividing by N−1 rather than N (the "ddof=1" form), because 30 years is a finite sample of the climate, not the whole population. For 450 values the difference from the population form is about 0.1%; for 30 monthly means it is about 2%.

On the R2 baseline the daily sigma is built the same way from R2's daily series. R1's per-hour files carry no sigma at all.

A note on composites. A composite map (several days, or several hours) divides its anomaly by the average of the members' sigmas. The strict sigma of a several-day average is somewhat smaller than that, because averaging smooths out variability, so normalized composites read a little less extreme than a strict calculation would give. WPC's method is defined per day and does not define a composite sigma; PyRe's choice is the standard simplification, and the subheader says "composite" whenever it applies.

11. Why does PyRe mask low wind speeds on normalized anomaly maps?

A normalized anomaly of +5σ at 850mb is meaningless if the actual wind speed is 3 m/s. The background flow is essentially calm — there is no jet or meaningful circulation to be anomalous. The σ denominator can be very small in regions of weak climatological flow, producing inflated sigma values that look dramatic but carry no physical significance.

PyRe applies a level-dependent absolute value threshold for wind speed normalized anomaly maps: grid points where the observed wind speed is below the threshold are masked to NaN before rendering.

Other variables (temperature, height, humidity) do not require this masking — their anomalies are physically meaningful at any value.

12. Why does CORe produce better maps than what PSL was showing?

The practical effect: features like the low-level jet (LLJ), frontal boundaries, and upper-level troughs are positioned more accurately at 0.703° than at 2.5°. A wind maximum that appears 200–300 km north of where you expect it on PSL's map may be correct at CORe's resolution. That is not an error — it is better data.

13. My CORe map looks different from the old PSL map for the same date. Which is right?

CORe, almost certainly. The differences are usually explained by:

1. Resolution: 0.703° vs 2.5° — PSL was averaging over grid boxes roughly 13× larger in area. Fine-scale features (LLJ cores, jet streaks, moisture plumes) were smeared.
2. Different reanalysis system: R1 and CORe use different data assimilation schemes, model backgrounds, and observational inputs. They are not expected to produce identical fields.
3. Improved observational coverage: CORe incorporates more recent observational datasets and better quality control even when retrospectively applied.

The best independent validation for a specific historical date is ERA5 (ECMWF, 0.25°, available free via Copernicus CDS) or the SPC mesoanalysis archive (observationally based, available for events back to the early 2000s at spc.noaa.gov).

14. What data sources are researchers actually using for case studies?

This varies by event date and paper vintage:

Important: If a paper or talk about a pre-2014 event (like the April 27, 2011 Super Outbreak) references HRRR, it is almost certainly either a hindcast (a model re-run using the HRRR configuration, which is a specialized research product) or a misidentified product. HRRR operational archives begin around 2014–2016.

For the 2011 Super Outbreak, researchers most commonly use ERA5 or NARR. CORe at 0.703° is coarser than either, so it is well suited to the synoptic pattern — the trough, the jet, the moisture return — and less suited to fine mesoscale structure. Use ERA5 or NARR when the question is about storm-scale detail.

15. What is the daily normal, specifically?

For a given calendar day, say April 27, the CORe daily normal is built as follows:

1. The 15 calendar days centered on April 27 (April 20 through May 4) are read from the archive's daily-mean files for each of the 30 base years, 1991–2020: 450 fields.
2. The mean and sample standard deviation are computed at every grid point across those 450 fields.
3. The result is stored, and every later map that needs April 27 reads it back. A composite builds all of its missing days in one pass over the union of their windows.

The first map to need a given day waits about ten seconds for the build. Everyone after reads the stored file.

The R2 daily normal, available by choice, is built the same way from R2's daily series at PSL, one calendar day at a time, then pooled over the same 15-day window.

16. What happens on February 29?

There is no February 29 normal. Not every year has one, and PSL's own normals leave the day out. A map for February 29 uses February 28's normal. With the 15-day window the two would be the same within rounding anyway.

17. What does the wind overlay show and does it cost extra fetches?

The wind overlay draws vectors, barbs, or isotachs (labeled speed contours) on top of any scalar field. It requires U and V wind components, taken at the map's own level — 10m winds for surface/single-level fields — and the map title states which (e.g. "850mb Wind Barbs", "10m Wind Barbs").

On composite maps: the overlay is the vector-mean wind over the same dates/hours as the composite — each of U and V is averaged across the selection, then drawn. Where wind direction varies between the composited times, the mean barb is shorter than any single day's wind; that's the correct composite, not a bug.

Fetch accounting: every (date, synoptic hour) is its own GRIB file. A 3-day daily-mean composite touches 3 × 4 = 12 files — one .idx fetch plus byte-range requests for just the needed records per file, run concurrently. When the mapped variable is already wind speed, U and V are fetched once and reused for the overlay — no additional requests. On any other variable, the overlay is a second fetch pass. Sub-monthly records are not disk-cached (monthly slices and all climatology are), so repeating one of those days re-fetches it.

Isotachs: contour the full-resolution speed field sqrt(U²+V²) every 20 kt starting at 30 kt (10 m/s / 15 m/s in metric); the density setting only affects barbs/vectors.

On Vector Wind Anomaly maps: the overlay shows anomaly vectors/barbs, (U_obs − U_climo, V_obs − V_climo). The arrows can point opposite the actual wind if the observed flow is weaker than the climatological flow.

On Raw and Normalized maps: the overlay shows the actual observed/composite wind components unless a future mode explicitly says otherwise.

18. What does "surgical byte-range extraction" mean?

PyRe never downloads an entire GRIB2 file. Instead:

1. It fetches the .idx index file (a few KB) which lists byte offsets for every field in the GRIB2.
2. It issues an HTTP Range: bytes=start-end request to retrieve only the bytes for the needed field(s).
3. The bytes are decoded in memory by cfgrib. No disk I/O.

This is the same technique NOMADS uses internally and what enables PyRe to respond quickly even for large files.

19. Where is data cached and why?

Normals (climatology) are stored in a shared bucket after their first computation: the CORe monthly, daily, and hourly normals, and the R2 and R1 normals for anyone who chooses that baseline. A normal depends only on the variable, level, calendar day or month, and hour, never on who asks, so one stored copy serves every visitor and every server. The first computation of a daily or hourly normal takes about ten seconds; afterwards it is a one-megabyte read.

Observation data (CORe fields) is not stored. It is read from the archive by byte range on every request, which is fast, and it means a map always shows what the archive holds today.

20. Are the normals computed in advance or on demand?

Both, by kind.

• Monthly normals were built once for every record the monthly archive carries, about 6,200 files, and stored. They never need rebuilding.
• Daily and hourly normals are built the first time a map needs them and stored. Computing every one in advance would mean reading roughly a quarter of a terabyte from the archive for normals most of which no map will ever ask for; building on first use costs the first visitor about ten seconds per normal and nothing thereafter.

All stored normals live in one shared bucket, so a normal built for one visitor serves everyone.

21. Why a 15-day window?

A single calendar day across 30 years is 30 samples, and 30 samples give a noisy mean and a noisier standard deviation: the normal for April 27 could differ from April 28's by more than the weather does. Pooling the 15 centered days gives 450 samples per normal and a smooth seasonal cycle, at the cost of blurring the normal by a week either way, which for a normal is no loss. This is WPC's method for its standardized anomalies, and PyRe applies it to every daily and hourly normal, on the CORe and the R2 baselines alike. Monthly normals need no window; a month already averages 30 days.

22. What do the CAPE/CIN parcel options mean, and how do they compare to SPC's?

CORe publishes three CAPE records (and matching CIN), exposed in the Level selector:

• Surface-based — the parcel lifted from the surface (SBCAPE).
• Mixed-layer (180-0 mb) — the parcel built from the lowest 180 mb of the atmosphere. Note that SPC mesoanalysis mixed-layer products use a 100 mb layer, so values are not directly comparable.
• Most-unstable (255-0 mb) — NCEP's "best" CAPE, drawn from the lowest 255 mb; this is the conventional MUCAPE proxy in NCEP products and captures elevated instability that surface-based CAPE misses (e.g. north of a warm front).

Labels state the layer depths explicitly so maps are honest about which definition is plotted.

23. Why does PyRe's MSLP look weaker than GFS maps over the Rockies in summer?

"Sea-level pressure" over high terrain is an extrapolation, and different reduction methods disagree most under strong surface heating. A concrete comparison for July 7 2026 18z (the Colorado thermal low):

PyRe plots MSLET, the closest GFS-comparable reduction CORe publishes (CORe has no PRMSL). Two residual differences remain: PRMSL's Shuell reduction is known to deepen (arguably exaggerate) summer heat lows over elevated terrain, and CORe is an ensemble mean at T170 (~0.7°) while the GFS analysis is a single 0.25° field — averaging members smooths extremes. Expect PyRe heat lows to run a few mb weaker than PRMSL-based maps; highs and oceanic lows agree closely.

24. What is a daily map, exactly?

A daily map reads the archive's own daily-mean file for each day: the average of all eight 3-hourly analyses, computed by the archive, one record per day. Earlier versions of PyRe averaged the four synoptic times themselves; that is gone.

A 3-hourly slice that names all eight hours is the same thing and is treated as a whole day: it reads the daily file and compares against the daily normal. Any smaller set of hours is a slice of hours, each member compared against its own hour's normal when the field has a daily cycle.

25. What does an "anomaly" of a composite show?

Exactly what it sounds like, once you know both halves. The observation side averages the selected grids: the daily files for a daily composite, every 3-hourly step for a range, the chosen hours times dates for a slice. The climatology side averages the matching normals: each selected time is paired with the normal for its own calendar day (and, for a field with a daily cycle, its own hour). The map is the first average minus the second.

That is mathematically identical to computing each individual time's anomaly and averaging those, since subtraction and averaging commute. So "the anomaly of a composite" and "the composite of the anomalies" are the same map. For the standard deviation a normalized composite divides by, see the note at the end of Q10.

26. Which climatology dataset is the baseline — R1, R2, or CORe?

CORe, on every time scale, unless you choose otherwise. Observations and normals then come from the same reanalysis run and the same archive, which is the point: an anomaly between two different reanalyses carries their disagreement inside it.

The choice is the gear on the Analysis card and travels with a shared link. The map's second subheader line always names the normal used, for example Baseline: Jul 15 18z · CORe-hourly 1991–2020.

27. What can I do without an account, and what do Free and Pro add?

You can make useful weather maps as a guest: any variable, any date since 1950, single times, short event windows (3-hourly ranges up to 3 days, daily composites up to 7 days, monthly means up to 3 months), and the wind, pressure, height, and temperature overlays. Guests get standard output, which prints a full letter page at 300 DPI.

A free account unlocks anomalies, normalized anomalies, and climatologies, longer periods (3-hourly ranges up to 7 days, daily composites up to 14 days, monthly composites up to 3 months), and saved maps. Larger maps, meaning any anomaly or climatology map or a composite over about 32 fetches, take turns on the server through a shared queue so one big job never slows everyone else down.

Pro raises the period limits to the server's own ceilings (a full season of daily composites, monthly composites of any length, 3-hourly ranges of several weeks), puts your large maps at the front of the queue, and adds print output at 300 DPI, which is poster size. Pro is $9.99 a month or $99 a year. See the pricing page for the current table.

Why the limits differ by time scale: a 3-hourly range reads one field per 3-hour step, a daily composite reads one daily-mean record per day plus a normal that costs about ten seconds per calendar day the first time anyone asks for it, and a monthly mean is one archive record per month. The limits follow the cost of the data, not a single arbitrary maximum.

28. Where do monthly maps and monthly normals come from?

Both from the CORe archive's own monthly-mean files: one record per month, the average of that month's 248 three-hourly analyses, computed by the archive from the same run as the 3-hourly and daily files. The monthly normal for a calendar month is the mean and sample standard deviation of those 30 monthly records, 1991–2020, built once and stored. The archive publishes a month about a day after it ends.

A note for anyone comparing with the Climate Prediction Center's monthly files. CPC keeps a separate monthly archive of CORe whose folder is named "CDAS clone." Those records come from a separate run of the CORe system: at 500 mb they differ from the archive's own monthly files by 5 to 7 meters point by point (as much as 40 meters in the winter storm tracks) while agreeing on the global average, which is exactly how two runs of one assimilation system diverge. PyRe does not use the clone run. Every number on a monthly map, observation and normal alike, comes from the one archive.

29. How are the normals built?

A normal is what "usual" means on a map: the average of a quantity over the base period 1991–2020, and the spread around that average (the standard deviation, or sigma). Every anomaly, normalized anomaly, and climatology map uses one. All of PyRe's normals are built from the CORe archive, the same source as the observations, so a map never compares one reanalysis against another.

Three kinds, one per time scale.

• Monthly normal. For a calendar month, the 30 monthly-mean records for that month from the archive's monthly files, averaged; sigma is the spread of those 30 means. Built once for every record the archive carries, and stored.
• Daily normal. For a calendar day, the archive's daily-mean files (each already the average of a day's eight analyses) for the 15 days centered on that day, in each of the 30 years: 450 fields. Their mean and sigma. Built the first time a map needs the day, then stored.
• Hourly normal. For a calendar day and one analysis hour, the 3-hourly file at that hour for the same 15 days and 30 years: 450 fields, that hour only. Built on first use, then stored. Used for 3-hourly maps of fields that change with the clock (Q8).

The 15-day window. Every daily and hourly normal pools the seven days before and after. One day across 30 years is too few samples for a steady normal or a trustworthy sigma; 15 days gives 450 (Q21). The window wraps around the year end, so January 3's normal includes December 27 through January 10. February 29 is left out and reads February 28's normal.

Derived fields. Wind speed, relative vorticity, and storm motion are not archive records; PyRe derives them from the wind components. Their normals are built the same way their maps are: derive the quantity for each member first, then average and take the spread. So the normal of wind speed is the average of 450 speeds, not the speed of an average wind.

What "sigma" is. The sample standard deviation of the pool (dividing by N−1). A normalized anomaly is the anomaly divided by it, so a value of 2 means two standard deviations from normal for that place, day, and hour (Q10).

Same record as the map. Each variable's normal is built from the same archive record its raw map reads: relative humidity from the archive's RH field, sea level pressure from the same reduction, and so on. Observation and normal are the same quantity from the same run, on the same grid.

Storage. Stored normals live in one shared bucket, named by variable, level, calendar day, hour, and base period. A normal built for one visitor serves everyone afterward; the first build of a daily or hourly normal takes about ten seconds.

The alternative baseline. The gear on the Analysis card switches a map to the R2 family for reproducing published work: R2 monthly and daily normals, built by PyRe from PSL's R2 series with the same window and sigma, and R1's published per-hour means (no sigma) for 3-hourly maps of diurnal fields (Q5, Q26).

Last updated: 2026-09-13 — add new Q&A pairs at the appropriate level as they arise.

30. Can the people who run PyRe see the maps I make?

No. Your saved maps, projects, and folders are readable only by your account; the database enforces that, and administrators cannot open them. What we do keep is an anonymous count of which kinds of maps get rendered: the variable, level, region, mode, and time scale, tied to a hashed visitor id rather than to a name or email. That tells us which maps people find useful. It does not tell us who made them, and it never includes your saved images.

31. Where does the sea surface temperature come from, and why are land and ice blank?

The Sea Surface Temperature variable is CORe's surface skin temperature, a calculated field in the archive's surface files from 1950 on. Over open water it is the sea surface temperature the CORe model was given, so that is what the map shows. Over land the same record is the ground's skin temperature, and over sea ice it is the ice surface, so those cells are blanked: land from the archive's land mask, and any water cell colder than seawater's freezing point (about −2 °C) as ice. Normals, anomalies, and normalized anomalies use the same record, so an El Niño month reads as a warm anomaly along the equator east of the date line. This is a reanalysis estimate on a 0.5° grid, not a measured ocean dataset; a long instrumental record such as NOAA's Extended Reconstructed SST is a separate product we do not carry yet.