GRIB-API definition
| Name | Maximum temperature at 2 metres | Abbreviation | mx2tu | Unit | K | paramId | 201 |
UERRA details
| Definition | Maximum temperature at 2 metres since previous post-processing |
| Validity | maximum since the previous post-processing |
| Comment | Please note that the specific height level above ground might vary from one Centre to another. |
WMO GRIB2 definition
| Parameter | ||
|---|---|---|
| Discipline | 0 | meteorological products |
| Parameter category | 0 | temperature |
| Parameter cumber | 0 | temperature |
| Type of statistical processing | 2 | maximum |
| Length of time range | post-processing step in hours | 1/3/6 |
| Level | ||
|---|---|---|
| Type of first fixed surface | 103 | specified height level above ground (m) |
| Scale factor of first fixed surface | 0 or 1*** | (m) or (dm***) |
| Scaled value of first fixed surface | 2 or 15*** | 2 / 1.5 m |
| Type of second fixed surface | all bits to 1 | missing |
| Scale factor of second fixed surface | all bits to 1 | missing |
| Scaled value of second fixed surface | all bits to 1 | missing |
*** option valid for MetOffice
9 Comments
Richard Mladek
How to specify intervals since previous post-processing? Will they be somehow fixed or changing according to archived steps which are varying for fc/an, models etc?
Per Unden
I am afraid that they are varying according to the post-processing steps. So it may be 1 hour, 3 hours or 6 hours. It makes this parameter rather difficult to use if you want to know the max/min over 24 hours as is observed from stations. But for the model there is really no practical alternative. The main advantage of these parameters is that you see the extremes during all the model time steps between post processing and then a mars script and compute can be used for a 12 or 24 hour min/max. It is like all the accumulated parameters, that the user has to decide on his/her final accumulation period.
But it is useful if the "Length of time range" is coded as stated above! (So one can double check).
Richard Mladek
The problem with the newly proposed definition "Surface air maximum temperature" with varying "Length of time range" (equal to 1 or 3 or 6) is that it would be matched sometimes to other already existing definitions. In our case for lengthOfTimeRange=6 it would be matched to paramId 121 (Maximum temperature at 2 metres in the last 6 hours). For lengthOfTimeRange=1 the definition does not exist and for lengthOfTimeRange=3 the definition exists (strangely) only for ecmf.
Per Unden
I think then there might be a case for further post-processing, by taking e.g. (in the hourly case) the last 6 values and computing the max/min resp and then archive that one as 6 h range. ?
BUT it would be messy since there is a variable pp frequency from 1-3-6 or maybe (not UERRA) longer. So the 6 hour ones are only possible to compute for certain pp times. And not a all for the first 5 hours. But the 6 hour ones can be computed at 6, 12, 18 hours fc length etc.
Is there really a problem that you have a match? It is only in the physical sense that they happen to be the same in some cases. You can have two different param id, one with variable time range and the other one with fixed.
The models themselves (when they are converted to GRIB2 internally) will have to output variable time range.
Is it a problem in the grib_api mapping? I think that can be handled?
I think it is best if we still can have the parameter with variable time range and abstain from the fixed ones. If it is very important for the users we might do the COMPUTE and have some double (some waste of space...) storage for some of the hours of the forecasts, if really needed.
OR we through away the hourly values and only archive the 6 hours ones. The disadvantage is if someone wants higher time resolution, it is not there anymore.
Perhaps then to store both 3h and 6h would be acceptable ? Maybe this is the best solution, TBD!
Per Unden
I think the 6 hour parameter will serve the purpose so I propose to go for that.
Richard Mladek
At the moment there is a bug in the current GRIB-API version for "Maximum temperature at 2 metres in the last 6 hours" - the "Length of time range" is not defined for WMO GRIB2 definition.
Per Unden
We have to do some "compute" on the model output GRIB files prior to archiving over a number of 1 or/and 3 hour files. The same problem exists for max 10m wind gusts.
Per Unden
I propose to revert to the variable time range option analogous to 10 wind gust as discussed in detail. I don't think there is a problem with mapping since you retrieve variable time range in the request and then read the time range from the GRIB2 information. The user should also know from the documentation what the time range should be and check against the GRIB2 information that it is correct.
Richard Mladek
The previous version of the definition with varying period was restored. The issue with mapping will be discussed during today's (local) meeting.