Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question :GRIB2 Lightning parameters should they mapped in a similar way to precip accumulation? #62

Open
richardweedon opened this issue Nov 25, 2020 · 3 comments
Labels
question Further information is requested

Comments

@richardweedon
Copy link
Contributor

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

@sebvi
Copy link
Contributor

sebvi commented Nov 26, 2020

Hello @richardweedon

I would use 0-17-4 (note that you are reporting the wrong units for that one, it is km-2 day-1) with a statistical process set to "accumulation" that would change the units to km-2 (but you need to be careful if you accumulate for less than 24h or a day, you will need a conversion day -> hours)

The reason why the units are km-2 day-1 is because m-2 s-1 would give you extremely small values: 1 km-2 day-1 (1 lightning per km2 per day) would be 1.157*10^-11 m-2 s-1

@amilan17
Copy link
Member

@wmo-im/tt-tdcf -- please see Sebastien's questions and contribute to discussion in issues.

@amilan17 amilan17 added the question Further information is requested label Sep 13, 2021
@amilan17
Copy link
Member

@richardweedon -- is this still an outstanding concern?

@amilan17 amilan17 added this to the noTargetMilestone milestone Sep 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants