# ERA5-Land GRIB1 accumulated fields: P1/P2 metadata inconsistent with documented forecast accumulation? **URL:** \ **Category:** Datasets and Usage\ **Created:** [23 September 2026 17:44 UTC](https://forum.ecmwf.int/t/era5-land-grib1-accumulated-fields-p1-p2-metadata-inconsistent-with-documented-forecast-accumulation/15354 "2026-09-23T17:44:34Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Lyubomir\_Durankev](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/l/cab0a1/32.png) [@Lyubomir\_Durankev](https://forum.ecmwf.int/u/Lyubomir_Durankev)\ **Post date:** [23 September 2026 17:44 UTC](https://forum.ecmwf.int/t/era5-land-grib1-accumulated-fields-p1-p2-metadata-inconsistent-with-documented-forecast-accumulation/15354/1 "2026-09-23T17:44:35Z")
Hello, I am trying to verify the correct hourly interpretation of `surface_net_thermal_radiation` (STR, ECMWF parameter 177) downloaded from the CDS `reanalysis-era5-land` gridded dataset in GRIB format. I am aware of the ERA5-Land documentation explaining that accumulated variables are accumulated from the beginning of the 00 UTC forecast to the end of each forecast step, and that hourly values therefore need to be derived from consecutive forecast steps: > **[ERA5-Land: data documentation - Copernicus Knowledge Base - ECMWF Confluence...](https://confluence.ecmwf.int/spaces/CKB/pages/140385202/ERA5-Land+data+documentation)** This is also consistent with the numerical behavior of the STR data I downloaded. However, I am seeing an apparent contradiction with the GRIB1 metadata in the actual files delivered by CDS. I downloaded four small January subsets (2018 and 2020, two locations) and inspected all 2,976 GRIB messages / 11,904 grid-cell values. Two independent decoders produced identical numerical values. For every message I find: - timeRangeIndicator (TRI) = 4 - time unit = hour - P2 - P1 = 1 The sequence is: Validity 00 UTC: reference = previous day 00 UTC P1/P2 = 23/24 Validity 01 UTC: reference = current day 00 UTC P1/P2 = 0/1 Validity 02 UTC: reference = current day 00 UTC P1/P2 = 1/2 … Validity 23 UTC: reference = current day 00 UTC P1/P2 = 22/23 Taken literally, these P1/P2 values appear to describe individual one-hour intervals. That seems inconsistent with the documented ERA5-Land accumulation semantics, where step 2 should contain the accumulation from forecast start (00 UTC) through step 2 rather than only the 01–02 UTC interval. The numerical values strongly resemble cumulative values. For example, one grid cell contains: 01 UTC (P1/P2 0/1): -103372.375 J/m² 02 UTC (P1/P2 1/2): -176881.5 J/m² 23 UTC (P1/P2 22/23): -4872664 J/m² 00 UTC next day (P1/P2 23/24): -4999550 J/m² If the 02 UTC value is cumulative from the 00 UTC forecast start, the energy for the 01–02 UTC hour would be: -176881.5 - (-103372.375) = -73509.125 J/m² and therefore: -73509.125 / 3600 = -20.42 W/m² My questions are: 1. For `surface_net_thermal_radiation` from the CDS `reanalysis-era5-land` gridded GRIB product, are the packed STR values cumulative from the 00 UTC forecast start? 2. If so, is the correct hourly conversion: 3. If this is correct, why do the GRIB1 messages encode P1/P2 as 0/1, 1/2, 2/3, …, 23/24 rather than 0/1, 0/2, 0/3, …, 0/24? 4. Should P1/P2 therefore not be interpreted as the actual accumulation interval represented by the packed value for this product, or is this a metadata issue? 5. Can you also confirm the midnight handling? I also noticed a recent discussion of incorrect/missing metadata in some ERA5-Land GRIB files, although I am not assuming it is the same issue: > [@Missing/Wrong Metadata in ERA5-Land GRIB files](https://forum.ecmwf.int/t/missing-wrong-metadata-in-era5-land-grib-files/13775): > > Many of the GRIB files in the ERA5-Land dataset seem to have the wrong metadata and/or completely mismatch the [Parameter database](https://codes.ecmwf.int/grib/param-db/) As a simple example, let’s examine the [Glacier Mask](https://codes.ecmwf.int/grib/param-db/260294) invariant parameter, shortName glm. The GRIB (v2) file is called cicecap.grib An inspection with: gdalinfo cicecap.grib shows the correct geographic information and expected value range and statistics for a glacier cover mask. but the wrong parameter metadata: Driver: GRIB/GRIdded Binary (.grb, .grb2) Files: c… I have preserved the four original GRIB files and can provide a sample file, the exact CDS request, or the complete metadata dump for all 2,976 messages if useful. Thank you.