Branch

https://github.com/wmo-im/GRIB2/tree/issue-24

Summary and purpose

ECMWF is requesting 2 new parameters to represent convective rain and snow specific water content.

Action proposed

ECMWF kindly asks the team to review the proposal and accept it during the next session.

Discussions

ECMWF is developing the possibility to generate fields of specific water contents (kg/kg) for convective rain and snow.

These 2 parameters are equivalent to the existing specific rain and snow water content parameters:

• specific rain water content kg/kg discipline=0 category=1 code=85
• specific snow water content kg/kg discipline=0 category=1 code=86

It is unclear if the two parameters above represents only large-scale, non convective specific water content or the total (large scale + convective).
i
We would like to request two new parameters :
specific rain water content (convective) kg/kg
specific snow water content (convective) kg/kg

Detailed proposal

add a new entries in Code Table 4.2, discipline 0, category 1:

This proposal takes into account issues #15 and #20 to avoid code entry clash.

Branch

https://github.com/wmo-im/GRIB2/tree/issue-27

Summary and purpose

ECMWF is requesting new Fire weather forecasting parameters.

Action proposed

ECMWF kindly asks the team to review the proposal and accept it during the next session.

Discussions

Detailed proposal

add in Code Table 4.2, Discipline 2, Category 4:

Branch

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

Initial Proposal

The entry 8 in Code Table 4.2.4.2 looks truncated:

0 Particle number density m-3
1 Electron density m-3
2 Proton density m-3
3 Ion density m-3
4 Vertical total electron content TECU
5 HF absorption frequency Hz
6 HF absorption dB
7 Spread F m
8 h� m
9 Critical frequency Hz
10 Maximal usable frequency (MUF) Hz
11 Peak height (hm) m
12 Peak density (Nm) m-3
13 Equivalent slab thickness (tau) km

There are several non-ascii characters in there.
Our WMO rep Sebastien Villaume checked with Jeff Ator and we believe it should be:
h'F
(h prime F)

Can we please change this in all places it is mentioned e.g.
csv/CodeFlag.txt
GRIB2_CodeFlag_4_2_CodeTable_en.csv
xml/CodeFlag.xml

Thanks

Obtained from https://community.wmo.int/activity-areas/wmo-codes/manual-codes/latest-version
on 14th April 2020

4.0.table - templates 76 to 83 do not have "with source/sink" in their title.

Code table 1.3 - Production status of data
Says:
10-191 Reserved
Should be:
12-191 Reserved

Branch

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

Summary and purpose

This document proposes a new GRIB2 Code Table 4.2 parameter as well as a new table (4.249).

Action proposed

The @wmo-im/tt-tdcf team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

The tables contain a proposed addition to Table 4.2 as well as a new Table 4.248 within the GRIB2 section of the Manual on Codes. These are necessary to reflect new post-processing diagnostics and Nowcasting forecasts being implemented at the Meteorological Service of Canada. The additions further qualify the character of precipitation to reflect how information is transmitted to users in the context of a fully automated forecast. It is hoped that they are also sufficient for use by other Centers.

Detailed proposal

Addition to 4.2

New code table 4.249 (Character of precipitation)

Branch
https://github.com/wmo-im/GRIB2/tree/issue-06

~
In the context of Fire Forecasting, we are creating composite GRIB messages of several UTC time.

Typically, Fire forecasting (risk of fire) is only relevant during day time. Usually, when encoding a GRIB message, the time is UTC and fixed for the entire grid domain (which is ok most of the time). For Fire forecasting however, if we were using universal time, then the data value would be relevant only for part of the horizontal domain. For instance, 12Z will be relevant for Europe but will be useless for Australia.

One could save several GRIB messages for several UTC time so that all continents are covered at some point with relevant, meaningful values. But it is much more practical to create composite GRIB messages that are composed by stripes of local times so that the data represents for instance the values for "noon" everywhere.

Practically, depending on the resolution of the model, we create GRIB files with 4 stripes (6 hour zones), 8 stripes (3 hours zones), 12 stripes (2 hours zones) or 24 stripes (hourly zones). The stripes are perfect longitudinal time zones (not following countries like the time zones we usually know).

The bottom part shows an example of 8 stripes (3 hours timestep) for a forecast starting at 00Z. each stripes in longitudes 360/8 degrees wide, i.e. 45 degrees: 337.5 to 22.5 degrees is 00z+12 UTC, 22.5 to 67.5 degrees is 00Z + 09 UTC, .... 292.5 to 337.5 degrees is 00Z+15 UTC

My feeling is that I need a whole new set of templates in section 4 that do not represent "point in time" or "continuous or non continuous time interval" but a set of keys to represent "composite time".

Alternatively an entry could be added in code table 1.2 to specify that the time in section 2 is still the reference time of the forecast (that still needs to be recorded) but that the time specified in section 4 will be a composite. The problem then is that I don't know how to specify the number of "stripes" which should also be recorded.

If anyone have suggestions, comments, alternatives?

Branch

https://github.com/wmo-im/GRIB2/tree/issue-28

Summary and purpose

ECMWF is requesting new entries in Code Table 4.238: Source or sink

Action proposed

ECMWF kindly asks the team to review the proposal and accept it during the next session.

Discussions

In a coming cycle, ECMWF is planning to implement/incorporate a more detailed scheme for emissions using new sources and splitting existing ones into more specific contributions.
We also would like to propose an editorial change to amend the present Code Table 4.238 by changing the entry "0 - reserved" by an entry representing "other" or "everything else". This is useful when one need to produce a field with all the remaining emissions (or depositions) that were not explicitly produced separately using the other entries of the table.

Detailed proposal

change the following entry in Code Table 4.238

add the following entries in Code Table 4.238

Note:

• the sum of entries 12 and 13 is equivalent to entry 4

• the sum of entries 14, 15 ,16 is equivalent to entry 17

Summary and purpose

Additional template definitions for statistically processed values to complete the set of templates for spatio-temporal changing tiles

Action proposed

The team is requested to review the proposed new templates and approve it for implementation within the May 2019 fast-track (FT2019-2) update to the WMO Manual on Codes.

Discussions

The coding of spatio-temporal tiles at a point in time for deterministic forecasts (Product definition template number 55) and for individual ensemble forecast (Product definition template number 59) is already defined and used by the German weather service DWD. The definitions including a statistical process are missing. To complete the set of tile templates “average, accumulation and/or extreme values or other statistically processed values at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval” for deterministic and ensemble forecast of spatio-temporal changing tiles have to be defined.

The coding of spatio-temporal tiles at a point in time for deterministic forecasts (Product definition template 4.55) and for individual ensemble forecast (Product definition template 4.59) is already defined and used by Deutscher Wetterdienst (DWD), however, the definitions including a statistical process are missing. Ms Sibylle Krebber, DWD, proposed new product definition templates for deterministic and ensemble forecast of spatio-temporal changing tiles in order to complete the set of tile templates. The proposed templates composed of the existing PDT 4.55 and 4.59 and statistical process definitions.

The meeting agreed the proposal for FT2019-2 (Cat. 1d) as in the Annex to this paragraph, provided the validation will be finished by the end of June 2019. NCEP will assist the validation.

Detailed proposal

Please add 2 new entries in

Code table 4.0 – Product definition template number

Code figureMeaning

62Average, accumulation and/or extreme values or other statistically processed values at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval for spatio-temporal changing tiles at a horizontal level or horizontal layer at a point in time

63Individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval for spatio-temporal changing tiles

Please add 2 new templates:

Product definition template 4.62 – average, accumulation and/or extreme values or other statistically processed values at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval for spatio-temporal changing tiles at a horizontal level or horizontal layer at a point in time

Octet No. Contents

10 Parameter category (see Code table 4.1)

11 Parameter number (see Code table 4.2)

12 Tile classification (see Code table 4.242)

13 Total number (NT) of tile/attribute pairs (see Notes 1 and 2)

14 Number of used spatial tiles (NUT) (see Notes 1 and 2)

15 Tile index (ITN = {1,…, NUT}) (see Note 1)

16 Number of used tile attributes (NAT) for tile ITN (see Note 1)

17 Attribute of tile (see Code table 4.241)) (A = {A(1),…, A(NAT(ITN))}) (see Note 1)

18 Type of generating process (see Code table 4.3)

19 Background generating process identifier (defined by originating centre)

20 Analysis or forecast generating process identifier (defined by originating centre)

21–22 Hours of observational data cut-off after reference time (see Note 3)

23 Minutes of observational data cut-off after reference time

24Indicator of unit of time range (see Code table 4.4)

25–28 Forecast time in units defined by octet 24 (see Note 4)

29 Type of first fixed surface (see Code table 4.5)

30 Scale factor of first fixed surface

31–34 Scaled value of first fixed surface

35 Type of second fixed surface (see Code table 4.5)

36 Scale factor of second fixed surface

37–40 Scaled value of second fixed surface

Shape41-42 Year

43 Month

44 Day Time of end of overall time interval

45 Hour

46 Minute

47 Second

48 n – number of time range specifications describing the time intervals used to calculate the statistically processed field

49–52 Total number of data values missing in statistical process

53-64 Specification of the outermost (or only) time range over which statistical processing is done

53 Statistical process used to calculate the processed field from the field at each time increment during the time range (see Code table 4.10)

54 Type of time increment between successive fields used in the statistical processing (see Code table 4.11)

55 Indicator of unit of time for time range over which statistical processing is done (see Code table 4.4)

56–59 Length of the time range over which statistical processing is done, in units defined by the previous octet

60 Indicator of unit of time for the increment between the successive fields used (see Code table 4.4)

61-64 Time increment between successive fields, in units defined by the previous octet (see Notes 5 and 6)

65-nn These octets are included only if n > 1, where nn = 52 + 12 x n

65-76 As octets 53 to 64, next innermost step of processing

77–nn Additional time range specifications, included in accordance with the value of n. Contents as octets 53 to 64, repeated as necessary

Notes:

(1) See Note 1 under product definition template 4.55.

(2) For more information, see Part B, GRIB Attachment IV.

(3) Hours greater than 65534 will be coded as 65534

(4) The reference time in section 1 and the forecast time together define the beginning of the overall time interval.

(5) An increment of zero means that the statistical processing is the result of a continuous (or near continuous) process, not the processing of a number of discrete samples. Examples of such continuous processes are the temperatures measured by analogue maximum and minimum thermometers or thermographs, and the rainfall measured by a rain gauge.

(6) The reference and forecast times are successively set to their initial values plus or minus the increment, as defined by the type of time increment (one of octets 54, 66, 78, ...). For all but the innermost (last) time range, the next inner range is then processed using these reference and forecast times as the initial reference and forecast times.

Product definition template 4.63 – Individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval for spatio-temporal changing tiles

Octet No. Contents

10 Parameter category (see Code table 4.1)

11 Parameter number (see Code table 4.2)

12 Tile classification (see Code table 4.242)

13 Total number (NT) of tile/attribute pairs (see Notes 1 and 2)

14 Number of used spatial tiles (NUT) (see Notes 1 and 2)

15 Tile index (ITN = {1,…, NUT}) (see Note 1)

16 Number of used tile attributes (NAT) for tile ITN (see Note 1)

17 Attribute of tile (see Code table 4.241)) (A = {A(1),…, A(NAT(ITN))}) (see Note 1)

18 Type of generating process (see Code table 4.3)

19 Background generating process identifier (defined by originating centre)

20 Analysis or forecast generating process identifier (defined by originating centre)

21–22 Hours of observational data cut-off after reference time (see Note 3)

23 Minutes of observational data cut-off after reference time

24Indicator of unit of time range (see Code table 4.4)

25–28 Forecast time in units defined by octet 24 (see Note 4)

29 Type of first fixed surface (see Code table 4.5)

30 Scale factor of first fixed surface

31–34 Scaled value of first fixed surface

35 Type of second fixed surface (see Code table 4.5)

36 Scale factor of second fixed surface

37–40 Scaled value of second fixed surface

41Type of ensemble forecast (see Code table 4.6)

42Perturbation number

43Number of forecasts in ensemble

Shape44-45 Year

46 Month

47 Day Time of end of overall time interval

48 Hour

49 Minute

50 Second

51 n – number of time range specifications describing the time intervals used to calculate the statistically processed field

52-55 Total number of data values missing in statistical process

56-67 Specification of the outermost (or only) time range over which statistical processing is done

56 Statistical process used to calculate the processed field from the field at each time increment during the time range (see Code table 4.10)

57 Type of time increment between successive fields used in the statistical processing (see Code table 4.11)

58 Indicator of unit of time for time range over which statistical processing is done (see Code table 4.4)

59–62 Length of the time range over which statistical processing is done, in units defined by the previous octet

63Indicator of unit of time for the increment between the successive fields used (see Code table 4.4)

64-67 Time increment between successive fields, in units defined by the previous octet (see Notes 5 and 6)

68-nn These octets are included only if n > 1, where nn = 55 + 12 x n

68-79 As octets 56 to 67, next innermost step of processing

80–nn Additional time range specifications, included in accordance with the value of n. Contents as octets 56 to 67, repeated as necessary

Notes:

(1) See Note 1 under product definition template 4.55.

(2) For more information, see Part B, GRIB Attachment IV.

(3) Hours greater than 65534 will be coded as 65534

(4) The reference time in section 1 and the forecast time together define the beginning of the overall time interval.

(5) An increment of zero means that the statistical processing is the result of a continuous (or near continuous) process, not the processing of a number of discrete samples. Examples of such continuous processes are the temperatures measured by analogue maximum and minimum thermometers or thermographs, and the rainfall measured by a rain gauge.

(6) The reference and forecast times are successively set to their initial values plus or minus the increment, as defined by the type of time increment (one of octets 57, 69, 81, ...). For all but the innermost (last) time range, the next inner range is then processed using these reference and forecast times as the initial reference and forecast times.

We have a description as experimental in the cvs file. WE need to find a solution for providing always a description.

Currently we use two parameters in our models –
o lightning_flash_accumulation-PT01H
o lightning_flash_accumulation-PT03H

Both are supplied in NetCDF and have units of m-2. The lightning is both cloud to cloud and cloud to ground.
We need to map these across to the GRIB2 tables but couldn’t find an exact mapping. The WMO Code tables (version 26) provides the following –
0 Lightning strike density,,m-2 s-1
1 Lightning potential index (LPI),,J kg-1
2 Cloud-to-ground Lightning flash density,,km-2 day-1
3 Cloud-to-cloud Lightning flash density,,km-2 day-1
4 Total Lightning flash density,,km-2

The question is should these parameters be mapped in a similar way to precipitation accumulation i.e. use a rate code and then use the statistical process to sum it across a time period.
The tentative suggestion is to choose the WMO GRIB2 parameter code 0-17-0 Lightning Strike Density.
In the above code table, the units stated are m-2 s-1.
So could the statistical code be then used to then indicate it is a sum over 1 hour or 3 hours.
a) Is this the right approach
b) that the actual gridpoint values would then not need to be translated since they would remain as being in m-2?
c) Is the use of statistical code of 1 or 3 in units of hours ok to use when the WMO GRIB2 parameter code units are in m-2 s-1

Branch

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

Stakeholder

• MetNorway
• ECMWF

Summary and purpose

This document proposes new GRIB2 Code Table 4.2 parameters.

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The tables in this proposal contain parameters that will be of crucial importance for the Copernicus Arctic Regional Reanalysis project which has already started its production in 2020. These parameters have been widely used as GRIB1 local parameters in the HIRLAM numerical weather prediction community, and we thus believe they will be of high relevance outside the aforementioned reanalysis project.

Final Proposal

• 0-1, 62: Snow evaporation
  • Note 8: It is recommended to use parameter 148.
• 0-1, 148: Snow evaporation rate
  • Note 9: Snow evaporation is the accumulated amount of water that has evaporated from snow from within the snow covered area of a grid-box.
• 0-2, 47: Surface roughness for heat
  • Note 1: Surface roughness for heat is a measure of the surface resistance to heat transfer.
• 0-2, 48: Surface roughness for moisture
  • Note 2: Surface roughness for moisture is a measure of the surface resistance to moisture transfer.

Initial proposal

Proposed new entry for Code Table 4.2:

Comments:

1. Snow evaporation is the accumulated amount of water that has evaporated from snow from the snow-covered area of a grid-box. The existing parameter 62 Snow evaporation [kg m-2] should be deprecated
2. Surface roughness for heat is a measure of the surface resistance to heat transfer. It is a component of surface roughness.
3. Surface roughness for moisture is a measure of the surface resistance to moisture transfer. It is a component of surface roughness.

Branch

https://github.com/wmo-im/GRIB2/tree/issue-56

Summary and purpose

This issue propose to add 2 new entries in Code table 4.3 - "Type of generating process"

Action proposed

The team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes

Discussions

ECMWF would like to request 2 new entries in Code table 4.3: "First guess" and "Difference between first guess and analysis".
The "first guess" is the term commonly used in NWP to name the background data field used in the assimilation step to be blended with the observations to produce the analysis field. It is usually taken from a previous forecast run valid at the appropriate date and time.
The difference between the first guess and the analysis is used to evaluate how good the assimilation system is performing and to assess the quality of the background field.

At ECMWF, we store the first guess, the analysis and the difference between the two in our long term archive and we disseminate them to our member state.

Detailed proposal

ADD in Code Table 4.3 - Type of generating process

Octet Meaning
19 First guess
20 Difference between first guess and analysis
21-191 Reserved

Branch

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

Summary and purpose

"The UK Met office has an interest in using the GRIB Product definition template 4.10 ( percentile forecasts at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval) within the next few months. As you may be aware this is marked as ‘Experimental’ and requires validation before operational status can be granted. We are happy to undertake this role and will seek assistance from other centres in the next few weeks. If we can complete this in time for the deadline we will request its inclusion in FT2021-2." ~ Richard Weedon

Summary and purpose

DRAFT AMENDMENTS TO THE MANUAL ON CODES, VOLUME I.2 (WMO-NO. 306) BY FAST-TRACK PROCEDURE has been sent out on 28 July, 2020.

The focal points for codes and data representation matters are invited to review and comment by 29 September, 2020.

There are 13 proposals in Part B - Binary Codes: FM 92 GRIB, from No.1 to No.13.

Action proposed

Comments received will be recorded here.

Documents

FT-2020-2-Vol I.2.pdf

Summary and purpose

Since currently CodeFlag.xml does not have discipline information, for CodeTables 4.1 and 4.2, there are multiple elements associated with a single CodeFlag value, making it difficult to use them.
Adding discipline information to each GRIB2_CodeFlag_en element can resolve this issue.

Action proposed

• Extract SubTitle_en columns from CSV files and insert it as a SubTitle_en subelement to each GRIB2_CodeFlag_en element in CodeFlag.xml.
• Extract discipline information from SubTitle_en columns of CSV files and insert it as a Discipline subelement to each GRIB2_CodeFlag_en element in CodeFlag.xml.

The former would be easier although the latter would be more useful.

Discussions

Detailed proposal

This is to propose the following new entries

...

Branch

https://github.com/wmo-im/GRIB2/tree/issue-17

Summary and purpose

This document proposes new GRIB2 Code Table 4.2 parameters.

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation within the May 2019 fast-track (FT2019-2) update to the WMO Manual on Codes.

Discussions

The tables annexed herewith contain proposed additions to Table 4.2 of the GRIB2 section of the Manual on Codes. These are necessary to reflect new post-processing diagnostics and Nowcasting forecasts being implemented at the Canadian Centre for Meteorological and Environmental Prediction. It is hoped that they are sufficiently general for eventual use by other Centers.
We kindly request the IPET-CM to help us clarify whether the precipitation type probability parameters in Code Table 4.2, Product discipline 1 (hydrological products) may be used in the context of a general meteorology product. If not, we would be grateful for guidance on the proper procedure.

Detailed proposal

Proposed new entry for Code table 4.2

One table modification proposed:
GRIB2 - CODE TABLE 4.201, PRECIPITATION TYPE

New table Code table 4.246 - Thunderstorm intensity index

New table Code table 4.247 - Precipiation intensity index

Reference doc file: https://wmoomm.sharepoint.com/:w:/s/wmocpdb/EdX0NSgC3AZCiJYksEB1PkgBr8HPRRefpw2vnjqLWaldkA?e=CKlXm4

Reference meeting page: https://community.wmo.int/activity-areas/wmo-codes/meetings/ipet-cm-iii

Branch

https://github.com/wmo-im/GRIB2/tree/issue-20

Summary and purpose

This document proposes new GRIB2 Code Table 4.2 parameters.

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The tables in this proposal contain parameters that will be of crucial importance for the Copernicus Arctic Regional Reanalysis project which will start its production very soon. These parameters have been widely used as GRIB1 parameters in the hirlam numerical weather prediction community, and we thus believe they will be of high relevance outside the aforementioned reanalysis project.

Since the proposal has been submitted during the meeting and requires specific scientific expertise, the meeting decided to draft the amendment with a small group and then share it with other participants of the meeting. Dr Sebastien Villaume, ECMWF, offered to support the drafting work. The initial proposal is as in the Annex to this paragraph.

Detailed proposal
Proposed new entry for Code Table 4.2:

Comments:

1. Total solid precipitation includes the sum of all types of solid water, e.g. graupel, snow and hail
2. Normal flux is on a surface lifted to be normal to sun rays
3. Evaporation is the conversion of liquid into vapor
4. Sublimation is the conversion of solid state into vapor
5. Fog is defined as cloud cover in the lowest model level

Reference document: https://wmoomm.sharepoint.com/:w:/s/wmocpdb/EXE60TyG2FtCjAmwP90CvsoBPzAHgvYwHSOfCQO_wetbuA?e=TcgDt9

Reference meeting page: https://community.wmo.int/activity-areas/wmo-codes/meetings/ipet-cm-iii

Please see the below comment from 15 April 2020 by @jbathegit for the latest version of this proposal. The latest version is contained within a PDF file that was generated on 30 April 2019, and it contains detailed notes and diagrams which don't translate well to the markup schema for GitHub comments.

Regarding the GRIB templates
Grid definition template 3.20 – polar stereographic projection
Grid definition template 3.30 – Lambert conformal

We have a question regarding the key:
La1 - latitude of first grid point

Is this latitude meant to only increase, or can it decrease as well? The reason I ask is the following sentence for the LoV key (in the WMO templates doc):

"LoV is the longitude value of the meridian which is parallel to the y-axis (or columns of the grid) along which latitude increases as the y-coordinate increases (the orientation longitude may or may not appear on a particular grid)."

The phrase in bold is causing us some trouble. We have some GRIBs which have a scanning order of +i -j which different decoders treat differently. In Panoply the latitude always increases (scanning order is ignored) whereas wgrib2 uses the scanning order and the latitude decreases.
If it wasn't for that sentence, I would treat the latitude just like other grids and take the scanning order into account but it seems for Lambert specially there are different interpretations and many centres are producing data which conflicts in this regard.
Many thanks

Summary and purpose

The document proposes a methodology for reporting space weather in GRIB2.

Action proposed

The team is requested to approve the contents for validation and to consider the proposal for possible inclusion in November 2019 fast-track (FT2019-2).

Please note that it might be worthwhile to include the WMO IPT-SWeISS (Inter- Programme Team on Space Weather Information, System and Services) group for further review and discussions.

Discussions

At the IPET-DRC-II in Brasilia (August 2010), the team discussed ideas for the representation of space weather in GRIB2. This was initiated by a topical paper from the U.S., and the results are documented in item 2.3.11 of the final report from the meeting.

In accordance with the guidance provided by IPET-DRC-II, the NCEP Space Weather Prediction Center (SWPC) has worked closely with UK Met Office (UKMO) and US Air Force over the year 2010/2011 to develop a formal proposal for validation. Some validations were made, but then the validation process stopped and the proposal was withdrawn at the IPET-DRMM-II meeting in College Park in 2014.

Based on the increased relevance of space weather products and services in aviation and with respect to related ICAO and WMO activities in establishing global space weather centres, Ms Sibylle Krebber, DWD in cooperation with German Aerospace Centre (DLR) proposed the revision and extension of the GRIB2 data. The final goal is to harmonize space weather and meteorological data bases to foster inter-operability of the existing complex systems using the GRIB2 format.

It was suggested this issue should be raised to the CGMS Coordination Group on Space Weather, which will hold a meeting in May 2019, for their feedback, and IPET-SWeISS. IPET-CM will come back to this issue to reflect their feedback in the proposal.

In this context, a staff member of the Secretariat, who is supporting aviation issues of CAeM and ICAO, expressed by email that there is no ICAO aeronautical requirement in GRIB2 code form for the space weather advisory information in support of international air navigation to be made available to aviation end users. Rather, the required format of the space weather advisory information is: 1) abbreviated plain language; and 2) IWXXM GML (ICAO meteorological information exchange model, geography mark-up language).

The meeting noted the comment from the Secretariat and highlighted that the proposal is at the moment for voluntary production (Cat. 1d) by space weather centres, which use other formats, and hopefully become a standard in the future.

The meeting agreed the renaming of entry 3, Space product, in Code table 0.0 and the new unit in C-6 for FT2019-2 as in the Annex to this paragraph, and rest will be reviewed by CGMS and IPT-SWeISS. If validation is achieved by the end of June 2019, the proposal will be in FT2019-2

Detailed proposal

Reference document https://wmoomm.sharepoint.com/:w:/s/wmocpdb/EacdCFJIooVKhLy3Up8iOWEBUdwiiELorJE-kCLGGTiRJQ?e=f4nCvc

Reference meeting page: https://community.wmo.int/activity-areas/wmo-codes/meetings/ipet-cm-iii

Branch

https://github.com/wmo-im/GRIB2/tree/issue-16

Summary and purpose

ECMWF is requesting a new type of level to properly encode 2 new parameters: Most Unstable Convective Available Potential Energy (MUCAPE) and Most Unstable Convective INhibition (MUCIN)

Action proposed

ECMWF kindly asks the team to review the proposal and accept it during the next session.

Discussions

In a coming release of its IFS model, ECMWF will make available 2 new parameters, the most unstable CAPE and the most unstable CIN.
These 2 new parameters require to locate in the vertical air column the most unstable parcel of air (as shown in the attached pdf). The location of this parcel of air is grid dependent, which means it can't be encoded at a fixed height, an isobaric or isothermal level.
Following a recent proposal to introduce the entries 14-16 in the Code Table 4.5, we propose to define a new type of level called "Departure Level of the most unstable parcel" and assign it the code 17 (since this new type of level complements the newly created entries 14-16).

mucape.pdf

Detailed proposal

add a new entry 17 in Code Table 4.5:

Branch

https://github.com/wmo-im/GRIB2/tree/issue-53

Summary and purpose

This document proposes new templates to generalize percentile forecasts to a partitioning of any size called “quantile”, percentiles being 100-quantiles.

Action proposed

The team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

At ECMWF a new experimental global post-processed product, called “ecPoint-rainfall”, was introduced in April 2019 into the suite of real-time forecast products available for use by forecasters worldwide. The methods and products have attracted a great deal of interest, with many national met services and commercial customers requesting access to the GRIB data. ecPoint has also been the subject of many presentations (e.g. see https://youtu.be/QfZW34we2u8) and short articles in print and online (e.g. https://www.harry-otten-prize.org/news.html, scroll to “21 September 2019”). A more comprehensive paper (“A new low-cost technique improves weather forecasts across the world”) was submitted to Nature and is currently in the second review round (preprint available here: https://arxiv.org/abs/2003.14397). Meanwhile further work is underway to develop related products from extended range forecasts and from the ERA5 re-analysis, post-processing 2m temperature (ecPoint-temperature) as well as rainfall; for these we expect a broad user base to develop. Furthermore, ecPoint products can be generated from any global model or ensemble.
We would thus like to archive the new ecPoint data type, but due to the “unusual” format current GRIB definitions do not permit this. A particular limitation is that the most quantiles one can store, for a probabilistic product, is 101 (i.e percentiles using the percentile Forecasts templates). We would like to extend to embrace the “permille” concept, whereby one can store 1001 quantiles (i.e. equal to 0, 0.1, 0.2, 0.3, …, 99.8, 99.9, 100% stored in quantile as 0, 1 ,2 ,3, …, 998 999, 1000). Extending in this way provides the user with much more information on the distribution tails, which is where much of the value of ecPoint output lies, particularly for anticipating extreme events, such as extreme localised rainfall that can lead to devastating flash floods.

Detailed proposal

To generalize the concept of percentile to any partitioning called of any size called “quantile”, we propose to introduce 2 new templates based on the existing percentile templates 4.6 and 4.10. Please note that a quantile is now encoded on 2 octets to allow the encoding of “permille” (1000-quantile).

Product definition template 4.86 - Quantile forecasts at a horizontal level or in a horizontal layer at a point in time.

Octet No. Contents
10 Parameter category (see Code table 4.1)
11 Parameter number (see Code table 4.2)
12 Type of generating process (see Code table 4.3)
13 Background generating process identifier (defined by originating centre)
14 Forecast generating process identifier (defined by originating centre)
15–16 Hours after reference time of data cut-off (see Note)
17 Minutes after reference time of data cut-off
18 Indicator of unit of time range (see Code table 4.4)
19–22 Forecast time in units defined by octet 18
23 Type of first fixed surface (see Code table 4.5)
24 Scale factor of first fixed surface
25–26 Scaled value of first fixed surface
29 Type of second fixed surface (see Code table 4.5)
30 Scale factor of second fixed surface
31–34 Scaled value of second fixed surface
35-36 Total number of Quantiles q
37-38 Quantile value (between 0 and q )

Note: Hours greater than 65534 will be coded as 65534.

Product definition template 4.87 – Quantile forecasts at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval

Octet No. Contents
10 Parameter category (see Code table 4.1)
11 Parameter number (see Code table 4.2)
12 Type of generating process (see Code table 4.3)
13 Background generating process identifier (defined by originating centre)
14 Forecast generating process identifier (defined by originating centre)
15–16 Hours after reference time of data cut-off (see Note)
17 Minutes after reference time of data cut-off
18 Indicator of unit of time range (see Code table 4.4)
19–22 Forecast time in units defined by octet 18
23 Type of first fixed surface (see Code table 4.5)
24 Scale factor of first fixed surface
25–26 Scaled value of first fixed surface
29 Type of second fixed surface (see Code table 4.5)
30 Scale factor of second fixed surface
31–34 Scaled value of second fixed surface
35-36 Total number of Quantiles q
37-38 Quantile value (between 0 and q )
39–40 Year of end of overall time interval
41 Month of end of overall time interval
42 Day of end of overall time interval
43 Hour of end of overall time interval
44 Minute of end of overall time interval
45 Second of end of overall time interval
46 n – number of time range specifications describing the time intervals used to calculate the statistically processed field
47-50 Total number of data values missing in the statistical process
51–62 Specification of the outermost (or only) time range over which statistical processing is done
51 Statistical process used to calculate the processed field from the field at each time increment during the time range (see Code table 4.10)
52 Type of time increment between successive fields used in the statistical processing (see Code table 4.11)
53 Indicator of unit of time for time range over which statistical processing is done (see Code table 4.4)
54-57 Length of the time range over which statistical processing is done, in units defined by the previous octet
58 Indicator of unit of time for the increment between the successive fields used (see Code table 4.4)
59-62 Time increment between successive fields, in units defined by the previous octet (see Note 3)
63–nn These octets are included only if n > 1, where nn = 50 + 12 x n
63–74 As octets 51–62, next innermost step of processing
75–nn Additional time range specifications, included in accordance with the value of n. Contents as octets 51 to 62, repeated as necessary.

Notes:
(1) Hours greater than 65534 will be coded as 65534.
(2) The reference time in section 1 and the forecast time together define the beginning of the overall time interval.
(3) An increment of zero means that the statistical processing is the result of a continuous (or near-continuous) process, not the processing of a number of discrete samples. Examples of such continuous processes are the temperatures measured by analogue maximum and minimum thermometers or thermographs, and the rainfall measured by raingauge.

These new templates should be properly referenced in Code table 4.0
Octet No. Meaning
86 Quantile forecasts at a horizontal level or in a horizontal layer at a point in time
87 Quantile forecasts at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval

Branch

https://github.com/wmo-im/GRIB2/tree/issue-58

Summary and purpose

This document propose to add a new entries in Code table 4.2.

Action proposed

The team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

ECMWF is developing a new surface module to better describe surface processes. The model includes multiple model layers of snow, ice and soil. The temperature parameter is needed in all three types of layers (soil (level 151), snow (level 114) and ice (level 152)) and over the three types of surface for snow and ice (inland water (discipline 1), soil (discipline 2) and ocean (discipline 10)).
The proposal below addresses the missing temperatures for snow and ice in the relevant disciplines. With these new entries, the fields will be encoded using missing values where the domain does not correspond to the discipline. However, global parameters, not tied to a particular surface or discipline, would be very handy! This is possibly something to look at while developing GRIB3.

Detailed proposal

ADD in Code table 4.2 discipline 1 category 2 - Inland water
Octet Parameter Units
14 Snow temperature K

ADD in Code table 4.2 discipline 2 category 3 - Soil products
Octet Parameter Units
29 Ice temperature K

ADD in Code table 4.2 discipline 10 category 2 Ice
Octet Parameter Units
13 Snow temperature (over sea ice) K

Branch

https://github.com/wmo-im/GRIB2/tree/issue-26

Summary and purpose

This document proposes a new entry to GRIB table 4.16 “Quality value associated with parameter” to describe the probability of a geophysical parameter used in Product Definition Template 4.35 “Satellite product with or without associated quality values”.

Action proposed

The meeting is requested to approve the contents for inclusion within the next update to the WMO Manual on Codes.

Discussions

Several products used at EUMETSAT provide a confidence value associated with the geophysical product. It is proposed to update GRIB table 4.16 “Quality value associated with parameter” to include “Probability” for use in Product Definition Template 4.35 “Satellite product with or without associated quality values”.

This would be used e.g. in the EUMETSAT MSG Active Fires product with Product Definition Template 4.35 in order to indicate the probability of fire observed in a given pixel of the product.

Detailed proposal

Add the following entry to GRIB Table 4.16:

Branch

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

Summary and purpose

The Canadian Centre for Meteorological and Environmental Prediction has a requirement for a GRIB2 Product Definition Template that allows the representation of model ensemble climatology statistics for a given time interval, calculated across the full set of ensemble members and years in a reforecast. For instance, one might be interested in the average February temperature as a climate element from the reforecast. This global average would be calculated from the individual February averages of all members and over every year spanning the reforecast period. We propose a new PDT to meet this requirement.

Action proposed

The meeting is requested to consider this PDT as a draft proposal and provide input and eventual validation assistance.

Discussions

The Canadian Centre for Meteorological and Environmental Prediction has a requirement for a GRIB2 Product Definition Template that allows the representation of model ensemble climatology statistics for a given multi-year interval, calculated across the full set of ensemble members and years in a reforecast. For instance, one might be interested in the average February temperature as a climate element from the reforecast. For instance, this global average could be calculated from the individual February averages of all members for every year spanning the reforecast period.

The defining difference with other existing ensemble or reforecast PDTs is that we apply a temporal-ensemble statistic after the statistical processes that are purely over time. We propose a new PDT to meet this requirement, using PDTs 4.12, 4.60 and 4.61 as starting points.

**Description of the reforecast and example use case **
Usually, seasonal forecasts are expressed as an anomaly forecast or more precisely as a normalized anomaly forecast. In order to produce this forecast we need the forecast values and the historical distribution of these values. The historical distribution is computed on a series of historical forecasts, also called reforecasts. For each year in the reforecast period (1971-2010) and for each month in that particular year, the system runs 20 individual members for a period of 12 months. Then a month by month average is computed over the output of these runs. To characterize the distribution, the mean and the standard deviation is computed for one month and one lead time (as example, February, with one month lead time) with these 600 member-year couplets (20 members x 30 years ), with each couplet containing the time average over this month.

Detailed proposal

Add a new template:

Product definition template 4.64 – Statistics over an ensemble reforecast, at a horizontal level or in a horizontal layer in a continuous or non-continuous time interval

Octet No.	Contents
10	Parameter category (see Code table 4.1)  
11	Parameter number (see Code table 4.2)
12	Type of generating process (see Code table 4.3)
13	Background generating process identifier (defined by originating centre)
14	Forecast generating process identifier (defined by originating centre)
15	Indicator of unit of time range (see Code table 4.4)
16-19	Forecast time in units defined by octet 15 (see Note 1)
20	Type of first fixed surface (see Code table 4.5)
21	Scale factor of first fixed surface
22-25	Scaled value of first fixed surface
26	Type of second fixed surface (see Code table 4.5)
27	Scale factor of second fixed surface
28-31	Scaled value of second fixed surface
32	Type of ensemble forecast (see Code table 4.6)
33	Number of forecasts in ensemble
34	Number of years in the ensemble reforecast period (see Note 2)
35	First year of ensemble reforecast period
36	Last year of ensemble reforecast period
37	Total number of data values possible (or expected) in statistical process over the
	ensemble reforecast
38-39	Total number of data values missing in statistical process over the ensemble
	reforecast
40	Statistical process used to calculate the processed field over the ensemble reforecast
	(see Code table 4.10)
41-42	Year of model version date (see Note 3)
43	Month of model version date
44	Day of model version date
45	Hour of model version date
46	Minute of model version date
47	Second of model version date
48	Month of end of overall time interval (see Note 5)
49	Day of end of overall time interval
50	Hour of end of overall time interval
51	Minute of end of overall time interval
52	Second of end of overall time interval
53	n - number of time range specifications describing the time intervals used
	to calculate the statistically processed field
54-57	Total number of data values missing in statistical process
	58-69	Specification of the outermost (or only) time range over which statistical
	processing is done
58	Statistical process used to calculate the processed field from the field at
	each time increment during the time range (see Code table 4.10)
59	Type of time increment between successive fields used in the statistical
	processing (see Code table 4.11)
60	Indicator of unit of time for time range over which statistical processing is
	done (see Code table 4.4)
61-64	Length of the time range over which statistical processing is done, in units
	defined by the previous octet
65	Indicator of unit of time for the increment between the successive fields
	used (see Code table 4.4)
66-69	Time increment between successive fields, in units defined by the previous
	octet (see Note 3)
	70-nn	These octets are included only if n>1, where nn=69 + 12 x n
70-81	As octets 58 to 69, next innermost step of processing
82-nn	Additional time range specifications, included in accordance with the value
	of n. Contents as octets 58 to 69, repeated as necessary

Notes:
(1) The reference time in section 1 and the forecast time together define the beginning of the overall time interval.
(2) Octets 34-40 define a statistical process over both time and ensemble.
(3) This is the date to identify the model version that is used to generate the reforecast.
(4) An increment of zero means that the statistical processing is the result of a continuous (or near continuous) process, not the processing of a number of discrete samples. Examples of such continuous processes are the temperatures measured by analogue maximum and minimum thermometers or thermographs, and the rainfall measured by a rain gauge. The reference and forecast times are successively set to their initial values plus or minus the increment, as defined by the type of time increment (one of octets 59, 71. 83 ...). For all but the innermost (last) time range, the next inner range is then processed using these reference and forecast times as the initial reference and forecast time.

Reference document: https://wmoomm.sharepoint.com/:w:/s/wmocpdb/Eb_66UfSVf5OvNAUcogYf_8B_1_uelI4TSjJ0gPiYSprbw?e=hKHUrF

Reference meeting page: https://community.wmo.int/activity-areas/wmo-codes/meetings/ipet-drmm-ii

Branch

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

Discussion

I noticed that the Code/Flag table 3.1 has ONE entry for Mercator

Code table 3.1 – Grid definition template number
10 Mercator
11-12 Reserved

But the Templates document has TWO entries:

Grid definition template 3.10 – Mercator
Grid definition template 3.12 – transverse Mercator

Why is there a template for 3.12 but it's not in the table?

Proposal

Add Transverse Mercator to Code Table 3.1

Summary and purpose

Request for a new code table 4.2 entry set for surface adjusted wind

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The UK Met Office generates data from its atmosphere models with a model diagnostics of surface adjusted wind, which do not appear in the current GRIB parameter code tables. The respesentation this quantity within WMO GRIB2 tables would assist in the sharing of this data.

The atmosphere model generates values which are intended to be directly comparable to observed 10m winds, equivalent to BUFR table b entries

• 11 81 Model wind direction at 10 m
• 11 82 Model wind speed at 10 m

The naming could use the term surface adjusted, or could include the explicit text '10m'

Detailed proposal

• U
  • Discipline: 0
  • Category: 2
  • Name: u-component of wind (surface adjusted)

Full details are given in the attached document
Code.table.4.2.-.Parameter.number.by.product.discipline.and.parameter.category.-.Operational-1.docx

* Units: m/s

• V
  • Discipline: 0
  • Category: 2
  • Name: v-component of wind (surface adjusted)
  • Units: m/s
• speed
  • Discipline: 0
  • Category: 2
  • Name: Wind speed (surface adjusted)
  • Units: m/s
• direction
  • Discipline: 0
  • Category: 2
  • Name: Wind direction (from which blowing) (surface adjusted)
  • Units: degree true

RC

https://github.com/wmo-im/GRIB2/releases/tag/v27RC.4

Summary and purpose

To ensure that the machine-readable codes v27RC are valid and ready for testing during the comment period. 

Action proposed

1. Update script to ensure consistent output order
2. identify key individuals to test
3. Confirm file validation

Discussions

Machine-Readable Files

• CodeFlag.txt
• Template.txt
• CodeFlag.xml
• Template.xml

• make sure there are no other values besides 'Operational' first.

Branch

https://github.com/wmo-im/GRIB2/tree/issue-57

Summary and purpose

This document propose to add a new entries in Code table 4.2 discipline 10 to support the dissemination of Ocean modelling in GRIB.

Action proposed

The team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

ECMWF would like to request new parameters in Code table 4.2 discipline 10 to support the next version of its ocean model to be released in the coming years.

Detailed proposal

ADD in Code table 4.2 Discipline 10, category 3
Octet Parameter Units
4 Downward heat flux W m**-2
5 Eastward surface stress N m**-2
6 Northward surface stress N m**-2
7 x-component surface stress (see Note) N m**-2
8 y-component surface stress (see Note) N m**-2
9 Thermosteric change in sea surface height m
10 Halosteric change in sea surface height m
11 Steric change in sea surface height m

Note: The x- and y-components of surface stress are not necessarily equivalent to the u- and v- components (Eastward/Northward). The x- and y-components strictly follow the defined coordinates system which may or may not follow the eastward and northward directions.

ADD in Code table 4.2 Discipline 10, category 4
Octet Parameter Units
22 Water column-integrated heat content J m**-2
23 Eastward component water velocity m s**-1
24 Northward component water velocity m s**-1
25 x-component water velocity (see Note 2) m s**-1
26 y-component water velocity (see Note 2) m s**-1
27 Upward water velocity m s**-1

Notes:
(rename the existing Note to "1")
2: The x- and y-components of water velocity are not necessarily equivalent to the u- and v- components (Eastward/Northward). The x- and y-components strictly follow the defined coordinates system which may or may not follow the eastward and northward directions.

ADD in Code table 4.2 Discipline 10, category 191
Octet Parameter Units
4 Barotropic stream function m3 s-1

Branch

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

Summary and purpose

Request for a new code table 4.2 entry for Wet Bulb Potential Temperature

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The UK Met Office generates data from its atmosphere models with a model diagnostic of Wet Bulb Potential Temperature, which does not appear in the current GRIB parameter code tables. The representation this quantity within WMO GRIB2 tables would assist in the sharing of this data.

Finalized proposal

(edited by @jitsukoh May 28)

• Discipline: 0
• Category: 0
• Number: 32
• Name: Wet-bulb potential temperature
• Units: K

Branch

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

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:

• snow melt accumulated over a time period: Currently, in code table 4.2, there is a parameter called "snow melt" (discipline 0, category 1, entry 16) and a parameter called "upstream accumulated snow melt" (discipline 1, category 0, entry 15) both with units kg m-2 . These parameters should be deprecated because they already represents an accumulation (since the units are not kg m-2 s-1) and in principle can't be use with templates encoding statistical processing using code Table 4.10 (which changes units multiplying by time). We propose to deprecate both parameters and create a new parameter "snow melt rate" with units kg m-2 s-1 in discipline 1 category 0.
• accumulated runoff and drainage: Again, in code table 4.2, there are several "runoff", "runoff and drainage", etc. that are already accumulated parameters with units kg m-2. We would like to propose new parameters with units kg m-2 s-1 and deprecate the problematic parameters.

Detailed proposal

add in code table 4.2

add notes

• 1-0, 15: Upstream accumulated snow melt (see Note 4)
  • Note 4: It is recommended to use Snow melt rate instead (discipline 2, category 0, number 41).
• 0-1, 16: Snow melt (see Note 7)
  • Note 7: It is recommended to use Snow melt rate instead (discipline 2, category 0, number 41).

Branch

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

Summary and purpose

ECMWF is proposing a new set of templates to extend existing templates for use with local time

Proposer

Sebastien Villaume (ECMWF)

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

Following the recent validation of the new local time template (4.88), issue #6 , we would like to extend the concept to be used in EPS and in postprocessing models. WE also extend the local time to be be used with statistically processed parameters.

LocalTime.pptx

Detailed proposal

add in code Table 4.0 the entries for the new templates

Template 4.92 Individual ensemble forecast, control and perturbed at a horizontal level or in a horizontal layer at a local Time

Template 4.93 Post-processing analysis or forecast at a horizontal level or in a horizontal layer at a local Time

Template 4.94 Post-processing individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer at a local Time

TEMPLATE 4.95 Average, accumulation, extreme values or other statistically processed values at a horizontal level or in a horizontal layer at a local Time

Notes:
(1) This represents the length of time over which the statistical processing was applied. The local time defined in section 1 represents the end of this processing. For instance, a value of 24h corresponds to a statistical processing between the previous day at local time and this day at local time.
(2) This represents the number of statistically processed fields (or stripes) used to create the composite local time field. For instance a value of 8 means that 8 statistically processed fields have been used in the processing, each of them representing a section of 45 degrees of longitude (360/8) centered around the UTC time corresponding to the local time.
(3) This is the number of forecasts and time steps used to create the statistically processed fields. These implicitly have the same statistical process as defined in octet 27. If a forecast has 2 time increments (3 hourly day 1 to 5 then 6 hourly), it should be encoded as 2 forecasts with the same reference time, using the appropriate starting forecast time and time increments.
(4) This also represents the length of time range of the statistical processed fields. For instance, to create a 24h accumulation (encoded in octet 29-32), we could use several 3h accumulations, or 6h accumulation, a mixture of the two, etc.

TEMPLATE 4.96 Average, accumulation, extreme values or other statistically processed values of an individual ensemble forecast, control and perturbed at a horizontal level or in a horizontal layer at a local Time

Notes:
(1) This represents the length of time over which the statistical processing was applied. The local time defined in section 1 represents the end of this processing. For instance, a value of 24h corresponds to a statistical processing between the previous day at local time and this day at local time.
(2) This represents the number of statistically processed fields (or stripes) used to create the composite local time field. For instance a value of 8 means that 8 statistically processed fields have been used in the processing, each of them representing a section of 45 degrees of longitude (360/8) centered around the UTC time corresponding to the local time.
(3) This is the number of forecasts and time steps used to create the statistically processed fields. These implicitly have the same statistical process as defined in octet 30. If a forecast has 2 time increments (3 hourly day 1 to 5 then 6 hourly), it should be encoded as 2 forecasts with the same reference time, using the appropriate starting forecast time and time increments.
(4) This also represents the length of time range of the statistical processed fields. For instance, to create a 24h accumulation (encoded in octet 32-35), we could use several 3h accumulations, or 6h accumulation, a mixture of the two, etc.

TEMPLATE 4.97 Average, accumulation, extreme values or other statistically processed values of a post-processing analysis or forecast at a horizontal level or in a horizontal layer at a local Time

Notes:
(1) This represents the length of time over which the statistical processing was applied. The local time defined in section 1 represents the end of this processing. For instance, a value of 24h corresponds to a statistical processing between the previous day at local time and this day at local time.
(2) This represents the number of statistically processed fields (or stripes) used to create the composite local time field. For instance a value of 8 means that 8 statistically processed fields have been used in the processing, each of them representing a section of 45 degrees of longitude (360/8) centered around the UTC time corresponding to the local time.
(3) This is the number of forecasts and time steps used to create the statistically processed fields. These implicitly have the same statistical process as defined in octet 32. If a forecast has 2 time increments (3 hourly day 1 to 5 then 6 hourly), it should be encoded as 2 forecasts with the same reference time, using the appropriate starting forecast time and time increments.
(4) This also represents the length of time range of the statistical processed fields. For instance, to create a 24h accumulation (encoded in octet 34-37), we could use several 3h accumulations, or 6h accumulation, a mixture of the two, etc.

TEMPLATE 4.98 Average, accumulation, extreme values or other statistically processed values of a post-processing individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer at a local Time

Notes:
(1) This represents the length of time over which the statistical processing was applied. The local time defined in section 1 represents the end of this processing. For instance, a value of 24h corresponds to a statistical processing between the previous day at local time and this day at local time.
(2) This represents the number of statistically processed fields (or stripes) used to create the composite local time field. For instance a value of 8 means that 8 statistically processed fields have been used in the processing, each of them representing a section of 45 degrees of longitude (360/8) centered around the UTC time corresponding to the local time.
(3) This is the number of forecasts and time steps used to create the statistically processed fields. These implicitly have the same statistical process as defined in octet 35. If a forecast has 2 time increments (3 hourly day 1 to 5 then 6 hourly), it should be encoded as 2 forecasts with the same reference time, using the appropriate starting forecast time and time increments.
(4) This also represents the length of time range of the statistical processed fields. For instance, to create a 24h accumulation (encoded in octet 37-40), we could use several 3h accumulations, or 6h accumulation, a mixture of the two, etc.

Branch

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

Summary and purpose

Request for a new code table 4.5 entries for convective cloud level

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The UK Met Office generates data from its atmosphere models on surfaces of convective cloud levels, which do not appear in the current GRIB parameter code tables. The representation these quantity within WMO GRIB2 tables would assist in the sharing of this data.

• Name: Convective cloud layer bottom level
• Name: Convective cloud layer top level
• See attached document for details of the new entries -
  GRIB-CC-4.5.docx

Final proposal

(edited by @jitsukoh July 2)
New entries in Code Table 4.5
26: Convective cloud layer base
27: Convective cloud layer top
28 - 29 Reserved

Branch

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

Summary and purpose

Request for a new code table 4.2 entry for upward UV

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The UK Met Office generates data from its atmosphere models with a model diagnostic of upward UV, which does not appear in the current GRIB parameter code tables. The respesentation this quantity within WMO GRIB2 tables would assist in the sharing of this data.

The GRIB2 tables already include a Downward UV radiation 0-4-12 so upward appears a sensible extension

Finalized proposal

(edited by @jitsukoh June 17)

• Discipline: 0
• Category: 4
• Number: 15
• Name: Upward UV radiation emitted/reflected from the Earth surface
• Units: W m-2

Branch

https://github.com/wmo-im/GRIB2/tree/issue-15

Summary and purpose

This document proposes a solution for the problem of incorrect units of "Potential evaporation rate" in Code Table 4.2, Discipline 0, Category 1, Parameter 41

Action proposed

As part of the November 2020 fast-track updates, the existing parameter 41 should be retained in the tables but marked with a note, and a new parameter with the correct units should be added to the same discipline and category within Code Table 4.2. A similar approach was used previously for "Evapotranspiration" in Discipline 2, Category 0, Parameter 6.

Discussions

Discipline 0, category 1, parameter 41 is defined as "Potential evaporation rate" with units of W m-2. Given that W = J s-1 = kg m2 s-3, then the existing units of W m-2 equate to kg s-3, which seems odd since W m-2 are units normally used for flux parameters, not for an evaporation rate. Instead we believe that the correct units should be kg m-2 s-1 to conform with other rate parameters in this table, and also because the preceding parameter 40 ("Potential evaporation") is defined with units of kg m-2.

As far as we can tell, this parameter 41 has been in the GRIB tables going all the way back to 2010 (version 5), so this may be another example of an incorrect parameter that nobody is likely using but which has been carried on for years through the manuals as a holdover from the old GRIB1 tables (like "Evapotranspiration", which we dealt with last year at IPET-CM-3 in Marrakech) In fact, during that meeting last year, Atsushi noted that there may be many such questionable parameters lurking in the tables and that it would be beneficial (for any folks who had some spare time and were so inclined ;-) to do a thorough review of Code Table 4.2 to flag any and all such parameters, if for no other reason than to make sure they don't get propagated forward yet again into a future GRIB3.

Regardless of whether a larger cleanup effort is undertaken in the future, we believe it would make sense to go ahead now and correct the problem in the current Code Table 4.2 as follows:

Detailed proposal

Within Code Table 4.2, Discipline 0, Category 1:

• Add new Note (1) to existing parameter 41: "The listed units for this parameter appear not to be appropriate for potential evaporation rate. Instead, it is recommended to use parameter 122."
• Add new parameter 122 as "Potential evaporation rate" with units of kg m–2 s–1

Branch

https://github.com/wmo-im/GRIB2/tree/issue-59

Summary and purpose

Addition of a new entry in Table 4.2, discipline 0 (Meteorological products), category 1 (Moisture)

Action proposed

The team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

A new entry for precipitation of cloud ice analog to snow precipitation rate is requested to be able to distinguish between snow and cloud ice particle deposition.

Detailed proposal

ADD in Table 4.2, discipline 0, category 1:

Branch

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

Summary and purpose

Fix editorial inconsistencies in FT-2020-2 amendments found by copyeditor after codes were released. 

Action proposed

Branch

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

Summary and purpose

This document proposes a new GRIB2 Code Table 4.2 parameter.

Action proposed

The @wmo-im/tt-tdcf team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

Biometeorological indices are used to measure the level of discomfort of humans due to several environmental conditions. Three of them, The Heat index, the apparent temperature, and the wind chill index are already part of the grib2 code Table 4.2, product discipline 0. Two other biometeorological indices, the Universal Thermal Climate Index (UTCI) and the Mean radiant temperature (MRT) have recently been added to the grib2 Table 4.2, product discipline 20. This new family of indices now include in one value the effect of temperature, humidity, wind speed, and short and longwave radiation fluxes on the outdoor human body.
The Wet-bulb Globe Temperature (WBGT) is proposed to be added to the Grib2 table 4.2, product discipline 20. WBGT is another integrated index reported among more than 10 biometeorological indices (including UTCI and MRT) presented in the document from WMO/WHO “Heatwaves and health: guidance on warning-system development” (WMO/WHO, 2015[1]). Due to climate change, more actions are being taken towards the development of Heat-Health Warning Systems (HHWS). The report mentions that “The choice of method for assessing heat stress will depend on the resources available to HHWS developers”. This document illustrates the benefit of retrieving different variables out of the governmental meteorological agencies.
WBGT is part of the international certification (ISO, 1989[2]). It is largely used in many sectors for which physical activity is considered, such as occupational health, sport federations, and defense organizations. At the early stage, WBGT was measured on-site.

It is relevant to add WBGT in the list of reference variables because this variable is now being forecasted in numerical weather and climate systems. For example, WBGT is part of the Canadian national short-range forecasts since July 2019. It is available at the surface for each grid point and over any type of surface, land, water, and urban landscapes [3]. Another example is the experimental maps of WBGT produced at NCEP [4].

References

• WMO/WHO, 2015: Heatwaves and health: guidance on warning-system development G.R. McGregor, P. Bessemoulin, lead editor, and K. Ebi and B. Menne, editors.
• ISO 7243, 1989. Hot Environments – Estimation of the Heat Stress on Working Man, Based on the WBGT-index (Wet-bulb Globe Temperature). International Organization for Standardization (ISO), Geneva.
• Leroyer, S., Bélair, S., Spacek, L., Gultepe, I., 2018. Modelling of radiation-based thermal stress indicators for urban numerical weather prediction, Urban Climate, 25: 64-81. https://doi.org/10.1016/j.uclim.2018.05.003
• National Weather Service - Graphical Forecast (noaa.gov)

Detailed proposal

Addition to 4.2

Notes (for PDF)

Higher values indicate that heat stress is important. Interpretation of values can vary among organizations and use. See example in the ISO certification (ISO 7243 1989, 2017, and Parsons 2013).

Additional Notes

Higher values indicate that heat stress is important. Interpretation of values can vary among organizations. For example the American Conference of Government Industrial Hygiene suggests that the thresholds depend on the work hardness. In the ISO certification, thresholds are as follows (in oC):

WBGT > 32 : Very High Heat Stress
 28 < WBGT < 32 : High Heat Stress
 23 < WBGT < 28 : Moderate Heat Stress 
WBGT < 23 : Low Heat Stress

Regarding the Data representation template 5.42:
"Grid point and spectral data - CCSDS recommended lossless compression"

The title of this scheme mentions "spectral data", which is confusing me as it does not have the right keys for representing spectral packing. Isn't CCSDS just like JPEG and PNG? if so then it would only be for GRID-POINT data and not spectral.

Its Note (1) says:

"The intent of this template is to scale the grid point data to obtain the desired precision, if appropriate, and then subtract the reference value from the scaled field, as is done using data representation template 5.0..."

So it affirms my suspicions: It is for GRID-POINT data. Later the note mentions data representation template 5.0 which is again for grid-point data (Grid point data-simple packing)

Branch

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

Initial Statement

In this table, there is a Code Table entry 19 which reads:
19,,Precipitation type,,(4.201),Operational

This should be changed to:
19,,Precipitation type,,(Code table 4.201),Operational

Just like the other table entry 123 (Dominant precipitation type)

Branch

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

Summary and purpose

Request for a new code table 4.2 entry for cloud water mixing ratio

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

The UK Met Office generates data from its atmosphere models with a model diagnostic of cloud water mixing ratio, which does not appear in the current GRIB parameter code tables. The respesentation this quantity within WMO GRIB2 tables would assist in the sharing of this data.
There are already two different cloud ice mixing ratio GRIB2 code table entries:

• 0-1-82
• 0-6-23

each with a unit of measure of kg/kg so cloud water mixing ratio appears a logical addition.

It is not clear to us what the difference between these two quantities is, and why there is a moisture category and a cloud category entry

Finalized proposal

(edited by @jitsukoh June 17)

• Discipline: 0
• Category: 1
• Number: 148 149
• Name: Cloud water mixing ratio
• Units: kg/kg

Branch

https://github.com/wmo-im/GRIB2/tree/issue-22

Summary and purpose

We are looking for clarification on https://github.com/wmo-im/GRIB2/blob/master/GRIB2_CodeFlag_4_2_CodeTable_en.csv#L896.

Action proposed

1. update the parameter description to "Mean Direction of Combined Wind Waves and Swell"
2. if 1 is not possible add a note to explain that the parameter implies a mean direction?

Discussions

Requirements and purposes of the proposal along with other background information, which could be included in the SUMMARY OF MEETING REPORT.

Detailed proposal

Does 'Direction of Combined Wind Waves and Swell' intend to communicate a mean direction?

Please validate the XML and TEXT files for GRIB.
GRIB2_r26_candidate.zip

Thanks!

Branch

https://github.com/wmo-im/GRIB2/tree/issue-32

Summary and purpose

This document proposes new GRIB2 Code Table 4.2 parameters.

Action proposed

The Team is requested to review the proposed ocean wave model peak period/direction parameters and approve them for implementation within the May 2019 fast-track (FT2019-2) update to the WMO Manual on Codes.

Discussions

The tables below are proposed additions for peak wind wave direction, peak swell period and peak swell direction fields.

Primary, secondary and now third swells parameters are commonly produced by ocean wave models and made available for use by public and private marine interests. Wave period and direction can be described by a mean value (using different methods) or the value at the peak. Peak period of swell partitions is provided by the Canadian wave models.

Detailed proposal

Branch

https://github.com/wmo-im/GRIB2/tree/issue-25

Summary and purpose

New GRIB2 Code Table 4.2 entries for the physical atmospheric properties of seeing and sky transparency

Action proposed

The tables annexed herewith contain proposed additions to Table 4.2 of the GRIB2 section of the Manual on Codes, for new physical atmospheric forecast parameters, namely sky transparency (humidity component) and seeing. Interpretation notes are included.

Discussions

Initially discussed at Offenbach 2018 report

Seeing and transparency diagnostic forecast parameters have been produced for many years from NWP output at the Canadian Meteorological Centre. They are popular with amateur and professional astronomers, and were found useful in other applications where it is important to characterize the properties of sky light at a given time in the future. While up to now these fields were made available as non-georeferenced raster graphics, there is now a requirement to make these fields available as georeferenced data and as GRIB files.
Seeing is the term used in astronomy to qualify the steadiness or turbulence of the atmosphere. Turbulence causes rapid and random fluctuations of the optical path through the atmosphere. The twinkling of stars, for example, occurs in poor seeing conditions. The data product is a categorical index that provides a qualitative indication of transparency conditions (i.e. from "excellent" to "very poor").
Sky transparency qualifies the effect of atmospheric composition on the viewing experience. Light travelling through the atmosphere is subject to scattering, the amount of which depends on the presence of water vapour, aerosols or other constituents. Ideal transparency conditions produce a black night sky conducive to viewing faint astronomical objects, almost like being in outer space. In poor transparency conditions, which may occur even in cloud-free conditions, the deep sky background is grayish (not black), faint details are washed out and contrast is reduced.
The data product is a categorical index that provides a qualitative indication of seeing conditions (i.e. from "excellent" to "very poor").
More information can be found in these pages:

http://www.skyandtelescope.com/astronomy-blogs/imaging-foundations-richard-wright/seeing-vs-transparency-difference/

https://weather.gc.ca/astro/seeing_e.html

https://weather.gc.ca/astro/transparence_e.html

Detailed proposal

Proposed new entries for Code Table 4.2
Product Discipline 0 – Meteorological products, parameter category 19: physical atmospheric properties

Code Table 4.214 Environmental Factor Qualifier

Notes

(4) Parameter 38:
In astronomy, Sky transparency means the effect on the viewing experience caused by the scattering of light through atmospheric water vapour, aerosols or other constituents. Ideal transparency conditions produce a black night sky conducive to viewing faint astronomical objects, almost like being in outer space. In poor transparency conditions, which may occur even in cloud-free conditions, the deep sky background is grayish (not black), faint details are washed out and contrast is reduced.

(5) Parameter 39: Seeing means the steadiness or turbulence of the atmosphere in the context of astronomical observation. Turbulence causes rapid random fluctuations of the optical path through the atmosphere. The twinkling of stars, for example, occurs in poor seeing conditions.

Obtained from https://community.wmo.int/activity-areas/wmo-codes/manual-codes/latest-version on 14th April 2020

Template 4.83 is missing the octet for:
"Type of generating process (table 4.3)"

This is present in all other similar templates

Branch

https://github.com/wmo-im/GRIB2/tree/issue-54

Summary and purpose

This document propose to add a new entry for "potential evapotranspiration rate" in Code table 4.2 discipline 2, category 0.

Action proposed

The team is requested to approve the content of this proposal for inclusion with the next update of the WMO Manual on Codes.

Discussions

The Copernicus Climate Change Service (C3S) project ULYSSE (mULti-model hYdrological SeaSonal prEdictionS system) provides a “seamless” multi-model hydrological seasonal prediction system using four state- of-the-art hydrological models (HMs) at a spatial resolution of 0.1 deg globally. Four HMs (JULES, HTESSEL, mHM, PCR-GLOBWB) will deliver forecasts of surface temperature, total precipitation, evapotranspiration, potential evapotranspiration, snow water equivalent, snowmelt, total volumetric soil moisture, total runoff and discharge. All these parameters, except potential evapotranspiration are well defined in GRIB2. We would like to propose to include in Code table 4.2 discipline 2, category 0

PET ("potential evapotranspiration rate" also called "reference crop evapotranspiration" ETo) is defined as "the amount of water that would be evaporated and transpired by a short green crop (grass) of uniform height, completely shading the ground, if there were sufficient water available". If the "actual evapotranspiration rate" (ET) is considered "the net result of atmospheric demand for moisture from a surface and the ability of the surface to supply moisture, then PET is a measure of the demand side." There are numerous methods to estimate PET, e.g., the Thornthwaite equation (1948), Penman-Monteith equation (1965), Priestley–Taylor (1972), Hargreaves and Samani (1982). Since the PET is required for the estimation of irrigation rates worldwide, the FAO provided a standardisation procedure called the FAO Penman-Monteith equation (http://www.fao.org/3/x0490e/x0490e06.htm#equation ), which is commonly used in hydrological modelling and irrigation scheduling.

Detailed proposal

add an entry in Code table 4.2, discipline 2, category 0
Octet Meaning Units
40 Potential evapotranspiration rate kg m-2 s-1

Proposal

Add note to Code Table 4.2
Product Discipline 0 - Meteorological products, parameter category 13: aerosols.
"This category is no longer populated, please use "Product discipline 0 – Meteorological products, parameter category 20: atmospheric chemical constituents."

Discussion

In section 4, we have sets of Product Definition Templates (PDTs) for aerosol and for chemical constituents.

The templates for aerosols always refer to an "aerosol type" which is coded in Code Table 4.233 which in turn is only a proxy for the Common Code Table 14.
The templates for chemical constituent type always refer to an "atmospheric chemical constituent type" which is coded in Code Table 2.230 which is in turn is also a proxy for the same Common Code Table 14.
So, in principle, it is the same Common Code Table used for all aerosols and chemical constituents.

To specify the type of physical/chemical property, there are 2 sub-tables in the Code Table 4.2, namely the sub-table "discipline 0 category 13 - Aerosols" and the sub-table "discipline 0, category 20 - Atmospheric Chemical Constituents".
However, it seems that the first sub-table has never been used/populated apart from the first initial entry created in it, and one can see that many entries in the second sub-tables were intended to use with aerosols!

Questions

• Was it initially intended to use the aerosols PDT with code table 4.2 discipline 0, category 13 only and the chemical PDT with code table 4.2 discipline 0, category 20 only?
• if this is the case and the team would like to follow this, should we deprecate many entries in code table 4.2 discipline 0 category 20 and moved them into code table 4.2 discipline 0, category 13?
• or Should we decide to recommend to stop using/adding entries in code table 4.2 discipline 0 category 13 and only use the other table for both aerosols and chemical constituents.

I am personally in favor of the later option. In GRIB3, we will use the same template component for both the aerosols and the chemical constituents, with one extra template component for aerosols. This makes sense because the aerosol templates are simply a copy of the chemical constituents templates with extra keys to specify a particle size range.