10 metre wind gust

This parameter must be added to GRIB-API.

The period must be short (1-3 hours ideally) since wind has a big variability.

But the post-processing frequency varies over the forecast length so in general it is best to have since the last post-processing (1, 3 or 6 hours in general but could be longer but probably not in UERRA).

The problem with the newly proposed definition "10 metre wind gust" 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=3 it would be matched to paramId 228028 (10 metre wind gust in the last 3 hours). For lengthOfTimeRange=1 or 6 the WMO definition does not exist yet.

I suggested that we could choose in the last 3 hours as a best compromise (and also in order to have the same for all the models). As in the case of max/min T2m one has to do come "compute" for time steps when the post-processing is 1 hour.

I am confused. Do you suggest to archive only 3-hourly wind gust in UERRA archive? From the e-mail below I thought you want to archive wind gust with varying length of time range in MARS and only then to use MARS compute function to determine e.g. 3-hourly gust. The same must be clarified for tmin/tmax as it does not give too much sense probably to archive 6-hourly extremes (as I understood it by now) for e.g hourly outputs..

----- Forwarded Message -----
From: "Per Unden" <Per.Unden@smhi.se>
To: "Richard Mladek" <richard.mladek@ecmwf.int>, "Peter Jermey (peter.jermey@metoffice.gov.uk)" <peter.jermey@metoffice.gov.uk>
Sent: Wednesday, 14 October, 2015 11:57:33 AM
Subject: 10 wind gusts maximum over 24 (?) hours

...

I think the similar problem as for T2m max/min over a time range (last pp) exists for 10 m wind as well. I.e. the model will always produce a values since last pp which is usually varying. Again it may be of advantage to compute the max over the last 3 hours say, every 3 hours of the forecast (that is by doing COMPUTE after the model pp I think since we probaly don't want to change the model code for this). The models will when in GRIB2 output a parameter with a time range and the mars compute can find the max.

...

OK, the choice of a fixed period was mainly to adapt to the existing definitions of WMO which I did suggest. But it is probably a bad idea as in my previous suggestion, one would use information from a number of model postprocessed files and through away some information.

I retract my proposal and support what you already have above, maximum since previous post-processing step.

Please do the same for max and min temperature then (not in (or over) the last 6 hours.

I don't understand what the problem is that it may already map to something which already exists in WMO definitions, the last 3 or 6 hours?. For some time steps, e.g. a 6 hour forecast it would be possible to archive either, but I prefer to use the variable range. The same for retrieval, a fixed hour (3 or 6) would not work but specifying that it is since last post processing would (and then find out from GRIB2 what the time range is so the user can check).

There seem to be 2 options regarding GRIB-API:

1. to use three separate parameters with unique paramId 10fg1/10fg3/10fg6
2. to create a new parameter 10fg with varying length of time range which would be used for UERRA datasets (if class=ur)

All consequences on GRIB-API/MARS and UERRA users' should be considered before final decision.

On behalf of Per (moved from the wrong place here):

"I am against sticking the time range on to the parameter. There will probably be new ranges in the future and it is not a solution for the future. I think a parameter since last postprocessing step is the appropriate and the forecast length gives an indication if you know the model but generally, use the time range in the GRIB message."