code table 4.2: new hydrological parameters, part 2

[sebvi]

Branch

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

Summary and purpose

ECMWF is requesting new hydrological parameters for the EFAS, GLOFAS and ULYSSES projects.

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

ECMWF is operating several services for the Copernicus program in the domain of flood forecasting (EFAS/GLOFAS) and hydrological seasonal predictions (ULYSSES). For these projects new (or correct) parameters are needed:

• Discharge return period with units m3 s-1: This is a statistical measure of levels of discharge that are expected with a certain frequency, for a example the 100-year return period for the Thames river is 187 m3/s of discharge.
• Upstream area, units m2 : The area which contributes with water to that specific point/grid box. This is a static variable.
• Drainage direction: The direction of flow from a point in the grid - This is an integer that describes the direction of flow from each point. The integer goes from 1-9 for each of the principal directions of a 3*3 grid starting from the mid point. a 5 denotes no direction. This is also a static variable

Detailed proposal

add in code table 4.2	Discipline	Category	Code	Meaning	Units
2	0	43	Drainage direction	code table 4.250
2	0	44	Upstream area	m2

create new code table 4.250 Drainage direction	Code	Meaning
0	Reserved
1	South-West
2	South
3	South-East
4	West
5	no direction
6	East
7	North-West
8	North
9	North-East
10-191	Reserved
192-254	Reserved for local use
255	Missing

add in code table 4.10	Code	Meaning
12	Return Period

[amilan17]

@sebvi -- You can at least add links to specific comments like this: https://github.com/wmo-im/GRIB2/issues/86#issuecomment-843171347. or just copy the original text and post in a comment here...

[sebvi]

adding previous comments from issue #86

from @lemkhenter :

Drainage direction: this parameter is provided by a hydraulic terrain model. This type of model is interested in the neighboring grid points to which the water drop can orient itself. It is therefore a 3 * 3 grid around the point in question. So I agree with proposal.

from @SimonElliottEUM :

Noting @lemkhenter 's comment, it looks like a code table defining the "direction" of the neighbouring grid will be best. Not degrees.

from @lemkhenter :

In my opinion, this proposal requires further study for several reasons: 1- the direction parameter, like the wind direction, requires the designation of an origin and a direction of evolution. 2- In the field of hydrology, the terrain models do not always have rectangular / square meshes. some models have a triangular mesh for example. For these reasons and others on which specialists in the field can clarify, I propose to submit the proposal to a hydrology group for more detail and precision.

from @sebvi :

Thank you @lemkhenter for your comments.

1- I think all directions we have (wind, waves, ocean currents, etc.) all have an origin at the centre of the grid box. Do you have an example where it is not the case? In the case of cardinal directions and not degrees, it seems to me that the "North" will be the North regardless of the origin chosen and the direction of evolution is implicitly "towards North" (because away from North would be then towards South). Would it help if we rename the parameter "Drainage Cardinal Direction"? 2- If a model has different requirements, for instance triangle mesh as you suggests with only 4 directions (3 sides of the >?triangle + no direction), there is nothing that prevents adding other entries in the new table. For instance one could imagine to add "south south east", "east south east", "south south west", "west south west", etc.

from @sebvi :

Note that if we rename the parameter Drainage cardinal direction, we restrict future use cases, for instance someone using "up" "Down", "left", "right" (although I would not be in favor of this sort o use case!!)

from @SimonElliottEUM :

@lemkhenter suggests to "submit the proposal to a hydrology group for more detail and precision". This seems like a wise move to me. We are an expert team on data representation - not hydrology. In a similar way we take satellite related topics to the CGMS Task Group on Satellite Data and Codes

from @sebvi :

yes sure we can definitely do that. I don't have a contact point for an hydrology group (other than our own in-house group) so I am happy to take any suggestion.

[amilan17]

@amilan17 -- send out reminder for feedback

[sebvi]

Two domain experts were contacted, one responded

from Juan Bianchi

In my opinion, the proposed parameters are correct. Best regards, Juan.

we may need to contact again the second expert.

[sebvi]

We have reworked the parameters as requested during the last Fast Track cycle. We would like to go ahead with upstream area and Drainage direction.

We had another look at the Drainage return period. Considering that "return period" can available to a range of parameters, not only drainage, and that the method is a standard statistical method, see here: https://en.wikipedia.org/wiki/Return_period , we propose to withdraw the request for a new parameter and create a new statistical processing in code table 4.10 instead. it will allow, using the appropriate templates to specify the time span used to calculate the return period (20-years return period, 100-years return period, etc.)

I will update the proposal accordingly.

[sebvi]

branch updated

[amilan17]

@amilan17 - find second hydrologist to verify

[sebvi]

updated proposal with correct new table -> 4.250

[amilan17]

@jitsukoh this is the diff for validation: bcae367

[jitsukoh]

@sebvi @amilan17 thank you for updating the branch. I confirm that the branch is updated and this issue is moved to validated status.