code table 4.10: Most severe and most frequent precipitation type over a time period

[sebvi]

Branch

https://github.com/wmo-im/GRIB2/tree/issue92

Summary and purpose

Action proposed

The team is kindly asked to review and approve the contents for inclusion within the next update to the WMO Manual on Codes.

Discussions

At present, ECMWF IFS model outputs precipitation type (discipline 0, category 1, entry 19 using code table 4.201) at the specified output time (instantaneous), but this can miss precipitation events that happen between output times, particularly important when the precipitation is high-impact, e.g. freezing rain.
One of our member state have requested that we provide new additional parameters:

• Precipitation type (most severe) in the last 1 hour
• Precipitation type (most severe) in the last 3 hours
• Precipitation type (most frequent) in the last 1 hour
• Precipitation type (most frequent) in the last 3 hours

In the current code table 4.2, there is a parameter "dominant precipitation type" (discipline 0, category 1, entry 123), recently requested by Canada, also using code table 4.201. I can't see how this parameter can be used: since only 1 precipitation type can be specified at each grid point anyway, in the case of multiple type of precipitation within the grid box, one would expect that the only type specified is the dominant one.

It seems more reasonable to use the generic precipitation type parameter combined with a template allowing a statistical processing over time like it is done for traditional parameters with a type of processing coming from code table 4.10 (accumulation, average, min, max, difference, anomaly, etc.) However, this method would require new type of processing to represent "most frequent" and "most severe" and that applies specifically to categorical parameters like precipitation type, cloud type etc.

Regarding the scale of severity, ECMWF proposes (in order of decreasing severity):
Freezing rain
Freezing drizzle
Hail
Wet snow
Dry snow
Graupel
Ice pellets
Mixture of rain and snow
Rain
Drizzle

What I am not entirely sure is if the new processing type should be part of 4.10, eventually in a separate range in the table, with a note restricting the processing to categorical parameters.
Alternatively we could create a new set of templates using a different table but it means a lot of work as tens of new templates will be required to double all the existing templates using code table 4.10

Detailed proposal

add 2 new types of processing in code table 4.10:

Code	Meaning
100	severity
101	mode

[lemkhenter]

For the "more frequent" type, it is possible to add an entry in code table 4.10 (type of statistical processing) called most commonly occurring value (mode) which coincides exactly with the context of the proposition.

For the "most severe" type, unfortunately the code table 4.201 is not sorted in the order of severity proposed (if this was the case, we can take the minimum as the type of processing). the solution is to create a new table of types of precipitation sorted according to severity.

Code table 4.xxx – precipitation severity
Code figure meaning
0: reserved
1: Freezing rain
2: Freezing drizzle
3: Hail
4: Wet snow
5: Dry snow
6: Graupel
7: Ice pellets
8: Mixture of rain and snow
9: Rain
10: Drizzle

these types of processing will be applied to a field such as "type of precipitation" with discrete values between 0 and N.
The most suitable template is (Product definition template 4.1001 - cross-section of averaged or otherwise statistically processed analysis or forecast over a range of time)

[sebvi]

thank you for your comment @lemkhenter

I am not at all in favor of creating a specific table for the severity. It does not matter if code table 4.201 is not ordered and the ordering might be subject to discussion. It should be left for the data producer to decide their criteria of severity. What will also happen if one day someone requests a new precipitation type that should be inserted in the middle of the existing one?

Regarding "occurrence" vs "mode" I had a though myself about it. From a pure mathematical point of view the correct term to use is "mode" but I was unsure if non mathematicians would understand it. But I am happy to change "occurrence" to "mode".
We are planning to use these new types of processing with all the templates containing the "statistically processed" octets. At the moment i is 20-30 different product definition templates.

[sebvi]

branch updated

[jitsukoh]

@sebvi @amilan17 I confirm that this proposal is finalized and the branch is updated, and move this issue to "Validated" status.