A page to detail some of the changes users should expect when sub-hourly data is supported in ecCodes.
Introduction
The sub-hourly version of ecCodes adds support for data encoded in units below hours, namely in minutes (m) or seconds (s).
We will compare the before and after behaviour to illustrate what the sub-hourly version brings to ecCodes.
Decoding data (via grib_ls/grib_get)
Let's take an instantaneous example with the following temporal properties:
| Code Block |
|---|
====================== SECTION_4 ( length=1138, padding=0 ) ====================== ... 18 indicatorOfUnitOfTimeRange = 0 [Minute (grib2/tables/28/4.4.table) ] 19-22 forecastTime = 45 ... |
We can see that this is a field at 45 minutes into the forecast.
Now let's compare the two versions:
ecCodes
| Code Block |
|---|
grib_get -p step sample.grib2
45
grib_ls -m -j sample.grib2
{ "messages" : [
{
"domain": "g",
"date": 20220527,
"time": "0000",
"expver": "0001",
"class": "od",
"type": "fc",
"stream": "oper",
"step": 45,
"levelist": 1,
"levtype": "ml",
"param": 248
}
]} |
ecCodes sub-hourly
| Code Block |
|---|
grib_get -p step sample.grib2
45m
grib_ls -m -j sample.grib2
{ "messages" : [
{
"domain": "g",
"date": 20220527,
"time": "0000",
"expver": "0001",
"class": "od",
"type": "fc",
"stream": "oper",
"stepunits": "m",
"step": 45,
"levelist": 1,
"levtype": "ml",
"param": 248
}
]} |
You can see that the unit is added to the step/stepRange, and that within the MARS namespace the new key stepunits is added.
Now let's take a statistically processed example with the following temporal properties:
| Code Block |
|---|
====================== SECTION_4 ( length=61, padding=0 ) ====================== ... 18 indicatorOfUnitOfTimeRange = 0 [Minute (grib2/tables/13/4.4.table) ] 19-22 forecastTime = 45 ... 50 typeOfStatisticalProcessing = 2 [Maximum (grib2/tables/13/4.10.table) ] ... 52 indicatorOfUnitForTimeRange = 0 [Minute (grib2/tables/13/4.4.table) ] 53-56 lengthOfTimeRange = 15 ... |
We can see that this is a maximum starting at 45 minutes into the forecast, taken over a 15 minute interval, and thus ending at 60 minutes into the forecast.
Now let's compare the two versions:
ecCodes
| Code Block |
|---|
grib_get -p startStep,endStep,stepRange sample.grib2
45 60 45-60
grib_ls -m -j sample.grib2
{ "messages" : [
{
"domain": "g",
"date": 20220527,
"time": "0000",
"expver": "0001",
"class": "od",
"type": "fc",
"stream": "oper",
"step": 60,
"levelist": 1,
"levtype": "ml",
"param": 248
}
]} |
ecCodes sub-hourly
| Code Block |
|---|
grib_get -p startStep,endStep,stepRange sample.grib2
45m 60m 45m-60m
grib_ls -m -j sample.grib2
{ "messages" : [
{
"domain": "g",
"date": 20220527,
"time": "0000",
"expver": "0001",
"class": "od",
"type": "fc",
"stream": "oper",
"stepunits": "m",
"step": 60,
"levelist": 1,
"levtype": "ml",
"param": 248
}
]} |
You can see that the unit is added to the startStep/endStep/stepRange, and that within the MARS namespace, where the endStep is used for indexing, the new key stepunits is added.
Encoding data (via grib_set)
A key point in the way the sub-hourly encoding works is that:
| Panel |
|---|
The unit will always default to the largest possible canonical unit that can be used (s, m, h, d, ...), e.g. ..., 59m, 1, 61m, ... |
Note that hourly steps are kept without a unit to preserve backwards compatibility.
Let's return to the instantaneous example we had above, and set the step to some different values covering the example above:
ecCodes sub-hourly