-
Notifications
You must be signed in to change notification settings - Fork 9
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
code table 4.2: surface adjusted wind (UK) #89
Comments
I think these can be achieved using a type of first fixed surface set to "height above ground in metres" (103) and set the level value at 10. This is why I am not in favour of creating new parameters |
To be more explicit, the usual way to encode these parameters is: 10 m u component of wind:
10 m v component of wind:
10 m Wind speed
10m wind direction
|
Hello @sebvi thank you for the feedback. Our model provides wind outputs at all levels within the model. Our model also includes specific code which implements surface adjustments to provide a specific surface adjusted wind parameter set. So, there are two alternative formulations for these wind parameters in our model. We are already using the settings described for the ‘standard’ wind diagnostics from the model. We want to have alternative settings for the ‘surface adjusted’ versions of these 4 parameters so that downstream customers can access both sets and differentiate between the differently derived parameters. These are not deemed to wind parameters which happen to be at a vertical level of 10m. These are specifically adjusted parameters to represent wind at the surface. They are different parameter codes in our model. There are specific BUFR codes for this concept:
but no specific GRIB2 concepts. thank you for your consideration |
Hello @marqh, if I understand you correctly, the model is producing 10m wind parameters in 2 different ways but at the end, it is still the same parameters computed/derived. If it is 2 different processes you should be able to distinguish the two sets using the process identifiers octets that are made for this I believe. |
Request the following entries - |
Hello, @marqh @richardweedon and @sebvi |
@efucile I thought the way to convey the particularity of these parameters would be the background generating process identifier keys which are freely defined by the data producer. |
Apologies all this is out of my comfort zone so please bear with me. I have attempted to summarise a rather long email from my colleagues - A short explanation is: The aim being - |
@marqh @richardweedon It looks like the conversation is still open and will not be ready for FT22-1. If you need this sooner, then please finalize the proposal within a couple days and I will create a branch. |
@marqh @richardweedon @sebvi -- Will this proposal be ready for FT2022-2 before June 8? |
to be determined for during another fast-track cycle |
https://github.com/wmo-im/CCT/wiki/Teleconference-4.10.2022 meeting notes: not discussed |
https://github.com/wmo-im/CCT/wiki/Teleconference-21.11.2022 note: not discussed |
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
The naming could use the term surface adjusted, or could include the explicit text '10m'
Detailed proposal
Full details are given in the attached document
Code.table.4.2.-.Parameter.number.by.product.discipline.and.parameter.category.-.Operational-1.docx
The text was updated successfully, but these errors were encountered: