wmo-im / GRIB2

GRIB2
MIT License
22 stars 9 forks source link

Additional Fire Weather field to Code Table 4.2, Discipline 2, Category 4 (Fire Weather Products) #174

Closed AndrewBenjamin-NOAA closed 1 year ago

AndrewBenjamin-NOAA commented 1 year ago

Initial request

NOAA-NCEP-EMC/NOAA-GSL are requesting an additional entry to Code Table 4.2 Discipline 2, Category 4 (Land Surface products, Fire Weather category).

Amendment details

Add to Code Table 4.2, discipline 2, category 4:

Number Parameter Units
26 Wildfire potential (as defined by the US NOAA Global Systems Laboratory) Numeric

Comments

Note: The Wildfire Potential (HWP) is an index which reflects the severity of fire weather conditions on existing wildfires. It's planned to be calculated on an hourly basis using 10-m wind gust potential, 2-m dewpoint depression, and soil moisture availability. It does not attempt to predict the likelihood of the formation of new fires. Higher values denote more severe conditions.

This Index has similarities to the Fosburg Index and the Hot Dry Windy Index. The novelty of this new index is that it is intended to be applied to hourly model output, with new index values provided hourly.

The equation: HWP = 0.237 (G ^ 1.11) (DD ^ 0.92) ( (1.0 - M) ^ 6.95) S where G= 10m wind gust potential diagnostic (as defined by the NOAA Technical Memorandum OAR GSL-66) DD= 2m dewpoint depression M= Soil moisture availability in the top soil layer S= max (0, (25.4 kg/m2 - SWE) / (25.4 kg/m2)) where SWE= Snow water equivalent S reduces the HWP if no snow is on the ground.

Requestor(s)

Andrew Benjamin (NOAA-NCEP-EMC)

Stakeholder(s)

Enter list of stakeholder(s).

Publication(s)

Manual on Codes (WMO-No. 306), Volume I.2, GRIB code table 4.2, discipline 2, category 4

Expected impact of change

MEDIUM

Collaborators

Eric James (NOAA-GSL)

References

N/A. Manuscript in preparation of submission to Weather and Forecasting

Validation

No response

jbathegit commented 1 year ago

Hi @AndrewBenjamin-NOAA, and thanks for your submission. I'm a long-time member of WMO's task team on BUFR and GRIB, and in fact I also happen to work at NCEP/EMC myself, so it's nice to "meet" you! :-)

This seems like a fairly straightforward request, and it shouldn't be any problem to get this included as new entry 27 in the next manual 306 update in May 2023. But I do have a couple of questions:

Please let me know - thanks!

jbathegit commented 1 year ago

I've coordinated offline with @AndrewBenjamin-NOAA and Eric James from NOAA GSL, and we've agreed to the modified proposal as noted above. This is requested for the FT2023-1 update.

amilan17 commented 1 year ago

https://github.com/wmo-im/CCT/wiki/Teleconference-12-and-13.12.2022 notes:

@amilan17 will create branch and @jbathegit will update branch

jbathegit commented 1 year ago

Thanks @amilan17, and the branch has now been updated.

jbathegit commented 1 year ago

I see that this is listed as "In Validation" status, but it's just a single addition to an existing code table, so I really don't think this needs to be formally validated. But if anyone would really like to see a sample message, I can ask NOAA/GSL to generate one.

amilan17 commented 1 year ago

@jbathegit The 'in validation' phase covers validating sample data or just verifying that the branch is consistent with the proposal and the CSV and text are in good shape. So no need to generate a sample message for this.

One question: why is the number 27 and not 21?

jbathegit commented 1 year ago

@amilan17, we used 27 because that was the next number available after taking into account the original version of proposal #170

sebvi commented 1 year ago

@jbathegit : after we decided to remove one of the parameter in #170 , I think your parameter could use entry 26 no?

jbathegit commented 1 year ago

Hi @sebvi

We could change it to 26, but I don't see why that's necessary or in any way beneficial at this point, given that the branch has already been updated and notifications have already been made. There's no rule that all defined entries in a table need to be sequential, and in fact there are many examples of existing code tables with gaps of one or more "Reserved" (i.e. undefined) entries between ranges of defined entries. So why not just leave it as is (as entry 27) at this point?

jbathegit commented 1 year ago

OK, well never mind, as I see that @amilan17 has already gone ahead and changed the number to 26 in the branch and in the above discussion. So I guess that means we're switching to 26, but that means another tweak is still needed to the branch, to change the reserved range of the table from 28-191 to 27-191. I'll go ahead and do that now.

FYI @AndrewBenjamin-NOAA, please note that the new "Wildfire potential" entry is now going to be 26 instead of 27 in CT 4.2. I'm not sure if Eric James has a GitHub account, so could you please let him know about this late development? (Thanks! ;-)

amilan17 commented 1 year ago

https://github.com/wmo-im/CCT/wiki/Teleconference-10.01.2023 notes:

ready for FT