Closed antoinemerle closed 1 year ago
Dear @jbathegit
As reminder on MWS sequence, you made an interesting remark on the following part of the sequence :
0 40 192
Satellite channel bandwidth (first band)0 40 193
Satellite channel bandwidth (second band)0 40 194
Satellite channel bandwidth (third band)0 40 195
Satellite channel bandwidth (fourth band)
why don't we have 4 descriptors knowing they are exactly the same width and scale ?
we made a workaround and find a solution : would it be okay for you if we only request to create two new descriptors:
0 05 195
: band number : Numeric | 0 | 0 | 4 0 40 192
: satellite channel bandwidth : Hz | -8 | 0 | 26and replace the sequence then by :
1 02 004
- replicate the 2 descriptors 4 times0 05 195
- band number0 40 192
- Satellite channel bandwidth0 05 195
- band number = missingThe difference would be impact the current proposal :
Is this okay for you ?
Thanks a million in advance for your help
Dear @marijanacrepulja
code | name | unit | scale | ref | width | Mission |
---|---|---|---|---|---|---|
0-05-193 | Sub-satellite latitude | Degrees | 4 | -900000 | 21 | ICI, MWI |
0-06-194 | Sub-satellite longitude | Degrees | 4 | -1800000 | 22 | ICI, MWI |
For those two descriptors, you asked an interesting question :
what Sub-satellite latitude mean ?
after looking and ask scientist for it, I can tell you that the correct name should only be :
according to EUMETSAT scientists and definition :
Sub satellite Point is the point at which a line between the satellite and the center of the Earth. intersects the Earth's surface. The location of the point is expressed in terms of latitude and. longitude.
source https://kanchiuniv.ac.in/coursematerials/satcomm.pdf
Changing the name of :
Would it be better and more clear for you ? Thanks a million in advance
Antoine MERLE
Hello @antoinemerle
re: "Satellite channel band width", there's already an existing Table B descriptor 0-02-154 which you can use for this, and which in fact already has the same Hz | -8 | 0 | 26 specifications. So you don't need to propose a new F-X-Y number for this.
re: the proposed new 0-05-193 and 0-05-194, I have more often heard that point referred to as the "Satellite sub-point", rather than the "Sub-satellite point". However, there do appear to be ample references which use the latter term as well, so it's probably fine.
re: the proposed new 0-21-192 and 0-21-193, it's not clear what you mean by "low resolution" vs. "high resolution", given that both of these use the same Numeric | 4 | 0 | 14 specifications. But either way, there's already an existing Table B descriptor 0-21-166 for "Land Fraction" with Numeric | 3 | 0 | 10, so you could just use Table C operators to modify those specifications as needed, and therefore you shouldn't need to propose any new F-X-Y numbers for this.
re: the proposed new 0-07-195 and 0-07-196, I have the same question here as to what you mean by "low resolution" vs "high resolution", again given that both of these are proposed with the same specifications. And similarly, is there any way you could just use one of the existing height descriptors in Class 7 and, if needed, modify the specifications using Table C operators, rather than proposing new Table B descriptors? Or, if these are non-coordinate height values, you could also use the existing Table B descriptor 0-10-001 which has the exact same name as what you are proposing.
Dear Jeff,
re: "Satellite channel band width", there's already an existing Table B descriptor 0-02-154 which you can use for this, and which in fact already has the same Hz | -8 | 0 | 26 specifications. So you don't need to propose a new F-X-Y number for this.
Indeed you are completely right here :
the final result would be then
1 02 004 - replicate the 2 descriptors 4 times
0 05 195 - band number
0 02 154 - Satellite channel bandwidth
0 05 195 - band number = missing
==> only request to create one new descriptor in table B: 0 05 195
TODO @antoinemerle update the sequence for MWS and edit the issue accordingly to that recomendation.
also remove the extra entries from table B
re: the proposed new 0-05-193 and 0-05-194, I have more often heard that point referred to as the "Satellite sub-point", rather than the "Sub-satellite point". However, there do appear to be ample references which use the latter term as well, so it's probably fine.
Thanks for your time ==> great to hear TODO @antoinemerle update the table B
re: the proposed new 0-21-192 and 0-21-193, it's not clear what you mean by "low resolution" vs. "high resolution", given that both of these use the same Numeric | 4 | 0 | 14 specifications. But either way, there's already an existing Table B descriptor 0-21-166 for "Land Fraction" with Numeric | 3 | 0 | 10, so you could just use Table C operators to modify those specifications as needed, and therefore you shouldn't need to propose any new F-X-Y numbers for this. re: the proposed new 0-07-195 and 0-07-196, I have the same question here as to what you mean by "low resolution" vs "high resolution", again given that both of these are proposed with the same specifications. And similarly, is there any way you could just use one of the existing height descriptors in Class 7 and, if needed, modify the specifications using Table C operators, rather than proposing new Table B descriptors? Or, if these are non-coordinate height values, you could also use the existing Table B descriptor 0-10-001 which has the exact same name as what you are proposing.
According to us, it already exists some codes with "high resolution" in their name as the following code 0 07 071
Height (high resolution) , for us that justify the fact to have a descriptor for our needs.
I had a discussion with scientists, Here is the explanation of the height vs low
the MWS processor gets a variable “lsmdem_search_resol” (LSM=Land Sea Mask, DEM= Digital Elevation Model). This variable has the dimension n_resol (that also surface_type and surface_elevation will have in addition to the nscans,nfov dimensions), i.e. the variable provides two values (in kilometres, referring to distances). For the surface type/ elevation determination, any LSM/DEM grid points within this distance “lsmdem_search_resol” (1st and 2nd value) to the MWS FOV are collected. Hence, for the large distance (i.e. radius) more grid points are collected than for the smaller distance. From each of the two grid point collections, the fraction of land grid points is determined and saved as surface_type of the current MWS FOV for a high resolution and low resolution (i.e. based on a smaller or larger radius for collecting the grid points). So, basically, the high/low resolution refers to the “allowed distance” in km of a LSM/DEM map grid point to the current FOV. “Allowed” meaning included in the determination process of the respective quantity for the current MWS FOV.
We still need a distinction between the low vs higher resolution for the final user. Nevertheless, I hear your comments, we can maybe organize a meeting to discuss it. Maybe it will be quicker to fix this problem / suggestions.
I really thank you for your time and your advices.
EDIT on IASI L1C and L1D During our most recent interactions with our expert scientist in EUMETSAT, some small issues have come to light with the IASI-NG L1C and L1D BUFR representation. We have updated the specifications accordingly with @SimonElliottEUM
3 01 005
to the IASI L1C and L1D template.We added the following code to replace the two codes for identification of the originating center and sub-centre. Impacted sequences are those two sequences 3 10 197
(IASI-NG L1C) and 3 10 198
(IASI-NG L1D):
code | name |
---|---|
3 01 005 | Originating centre/sub-centre |
Hi @jbathegit
I follow your recommendations and I implemented the following changes with Simon Elliott
We won't create 4 new descriptors anymore, but only one new for Radius resolution : 0 05 0196
from : code | description |
---|---|
0 21 192 | Land fraction - low resolution |
0 07 195 | Height of land surface - low resolution |
0 21 193 | Land fraction - high resolution |
0 07 196 | Height of land surface - high resolution |
to : code | description |
---|---|
1 07 002 | Repeat 7 descriptors 2 times |
0 05 196 | Radius resolution |
2 01 132 | Change width (+4) |
2 02 129 | Change scale (+1 ) |
0 21 166 | Land fraction |
2 02 000 | Change scale (reset to 3) |
2 01 000 | Change width (reset to 10) |
We don't create 4 new descriptors but only one new for Band number : 0 05 195
From :
code |
description |
---|---|
0 40 192 | Satellite channel band width (first band) |
0 40 193 | Satellite channel band width (second band) |
0 40 194 | Satellite channel band width (third band) |
0 40 195 | Satellite channel band width (fourth band) |
to : code | description |
---|---|
1 02 004 | Repeat 2 descriptors 4 times |
0 05 195 | Band number |
0 02 154 | Satellite channel band width |
https://github.com/wmo-im/CCT/wiki/Teleconference-1-and-2.11.2022 notes:
EDIT : update the zip file with the definitions files
Dear @amilan17 , we updated the table B with the final code (chosen by us). please tell me if this is okay for you and for the secretary. We also added an element description column, as requested in your last comments.
Dear @marijanacrepulja and @SibylleK, Please find attached :
$ECCODES_DEFINITION_PATH/bufr/tables/0/local/1/254/0/
Thanks for your help and time,
I am at your disposal for any questions .
Dear @antoinemerle,
Thank you for providing the samples.
I had a look at the zip file and can only find sample BUFR files but not corresponding Eccodes tables.
As part of the validation process, all proposed BUFR descriptors, templates and code tables have to be entered into git hub branch. You can find the branch on the right hand side of the issue definition under Development. Please note the master table should be set to 40 and local table to 0 in the sample files. Because, 40 is the next version of the tables that will contain your proposed entries.The idea of the validation process is that we can download tables from the git hub, and decode provided samples.
I understand it is a lot of work, but we need to validate samples using BUFR tables from git hub, as Anna will be merging it into the table release's final branch.
Many thanks!
Dear @marijanacrepulja ,
I just updated the zip file with the definitions tables ( you can find it above in previous comment, I am sorry for the mistake).
As you requested, I tried to generate my products with table master V40 (and V39) , but the latest Eccodes V2.27.0 (delivery date August 23) does not allow me to create a BUFR file with any Master table version above 38 (included).
When trying to create a product I got the following error:
ecCodes assertion failed: `included_fname' in /tmp/eccodes-2.27.0-Source/src/grib_parse_utils.c:639
According to Eccodes documentation :
The latest time BUFR received a WMO master table version update is with the release Eccodes 2.26.0 ( source )
Dear @antoinemerle,
Thank you for updating the zip file.
To create samples with master table version 40. You should create locally mkdir -r mydefinition/bufr/tables/0/wmo/40/
For the purpose of validation, all new entries have to be in git hub branch, so any software for decoding/encoding BUFR can handle the samples provided.
Hope this helps.
Many thanks, Marijana
It is always safer to set the FULL PATH of your own definitions in the environment variable Something like export ECCODES_DEFINITION_PATH=$PWD/mydefinition
Hi @shahramn, I fully agree with you and this is actually the case in my configuration :
echo $ECCODES_DEFINITION_PATH
/usr/src/eccodes/share/eccodes/definitions/
echo $ECCODES_DIR
/usr/src/eccodes/
The error I shared was rendered at runtime, while encoding the BUFR file, maybe when running the script, python is not picking the right one. I will investigate.
Hi @marijanacrepulja Thanks for the input and help with version 40 :
mkdir -r mydefinition/bufr/tables/0/wmo/40/
copy latest element.table sequence.def and all codetables into themydefinition/bufr/tables/0/wmo/40/
updateelement.table
,sequence.def
andcodetables
with new definitions
I definitely will do it today.
One additional question, I can commit all the changes in the same branch ? Right ?
Thanks
Hi @antoinemerle
Yes, having all the changes in one branch is convenient.
Many thanks!
https://github.com/wmo-im/CCT/wiki/Teleconference-21.11.2022 notes: @jbathegit will be able to review sometime next week. @antoinemerle is updating the branch @marijanacrepulja and @SibylleK will validate
Dear @amilan17 , we updated the table B with the final code (chosen by us). please tell me if this is okay for you and for the secretary.
@antoinemerle -- looks good so far.
@antoinemerle -- can you add acronyms to this CSV? acronyms.csv
@antoinemerle -- can you add acronyms to this CSV? acronyms.csv
@antoinemerle -- can you add acronyms to this CSV? acronyms.csv
Dear @amilan17 what acronyms ? ( Can you give me an example just for me to know.) @amilan17 : You've noticed that I pushed my changes in my branch, efucile already made some changes : I take a note that I will have to update my script to update also the XML tables in the next delivery.
Dear @marijanacrepulja @SibylleK : I just uploaded the table 40 and the corresponding products here:
Please let me know if I missed something wmo_delivery_v40.zip
Thank you all for your time and dedication.
Antoine
https://github.com/wmo-im/CCT/wiki/Teleconference-21.11.2022 notes: @jbathegit will be able to review sometime next week
I have no further comments or concerns - thanks!
@antoinemerle acronyms like: MWI, ICI, SCA, IAS 1, MWS...
Dear @amilan17 I just commit the changes : SHA code : b71910af37c17ddefd60f3b6c56f980b7cd2b732
link of the commit : https://github.com/wmo-im/BUFR4/commit/b71910af37c17ddefd60f3b6c56f980b7cd2b732
Dear @antoinemerle, I just wanted to validate the examples using the branch for this issue, but for the validation the Table D entries are also needed in the branch. Is it possible for you to also add the sequences to the branch?
Dear @SibylleK , It is done. : fc9199027b8e452429893e75a4d7b3f7a740165a
click here to see the commit
I already did the changes but forgot to run the git commit
.
All the product have been added in the BUFR_TableD_en_10.csv
now
It should be okay , I am double-checking.
@efucile I assume we need once more to generate the corresponding XML
and txt
file from that BUFR_TableD_en_10.csv
@antoinemerle - thank you for updating the branch. The XML and TXT files are generated automatically and Enrico's handle is just part of the script for legacy reasons.
@antoinemerle - thank you for updating the branch. The XML and TXT files are generated automatically and Enrico's handle is just part of the script for legacy reasons.
HI @amilan17 I had to change the sequence for MWS. as the commit title is saying :
Following another check from the EUMETSAT scientists, we needed to change the resolution from 100MHz to 1MHz for the Satellite Channel band width. Meaning we had to add 2 to the scale and we had to change the sequence for MWS.
May you run again the the script for the XML and TXT Files ?
Thanks a million
https://github.com/wmo-im/CCT/wiki/Teleconference-12-and-13.12.2022 notes:
sibylle was unable to validate the large number of subsets; @antoinemerle can provide a smaller product for testing.
@SibylleK , please find attached the MWI and ICI with "only" 5,576 subsets representing 4 scan lines. Tell me if this is better for you :) (I will provide tinier ones for SCA two..) MWI AND ICI.zip
Question for you also, because Anna did not write it here but here is the list of changes still to be applied : can you confirm and/or correct me :
do I miss anything?
@antoinemerle -- I'm in the middle of a deep consistency analysis of the CSVs and and it's easier for me to update the branch directly for editorial things like you mentioned above. I will probably have an update of the branch by end of the day with some follow up questions. Do you mind waiting on any further updates until then?
@amilan17 no worries at all on my side at all ! 👍 Thanks for letting me know
@antoinemerle I completed the consistency review and made some basic editorial changes for you to approve of in PR #141.
I have some other suggestions and questions.
@amilan17 Thank you very much for the editorial changes which already include some changes of the units!
There are still some inconsistencies regarding the units in 033112 (deg with a capital D), 003029, 003030, 008098 and 021026 (Code table with a capital T) and the new Flag tables in BUFRCREX_TableB_en_33.csv which also have a capital T.
@antoinemerle the new MWI-BUFR examples still have 27880 subsets and the version number is set to 38:-( Could you check? Regarding the ICI, the BUFR also have the same number of subsets and version 38, but in this case I got another error ("Errormessage: End of descriptors in repetition list"), which indicate that the sequence does not work as it is in the branch. It seems that the last 23 entries of sequence 310080 are not included in the descriptor of the branch.
There are still some inconsistencies regarding the units in 033112 (deg with a capital D), 003029, 003030, 008098 and 021026 (Code table with a capital T) and the new Flag tables in BUFRCREX_TableB_en_33.csv which also have a capital T.
@SibylleK Thanks for letting me know. They should be fixed now.
Dear @SibylleK thanks for the feedback.
Please find the correct files attached : MWI_and_ICI.zip
I fixed the issue, It was due to a wrong copy/past (I missed the last 23 lines). thanks a lot for spotting that issue.
Some editorial updates are in this PR: #141
https://github.com/wmo-im/CCT/wiki/Teleconference-10.01.2023 notes:
after PR approval @amilan17 will merge PR, @marijanacrepulja still reviewing content, @SibylleK will review branch and can put output from examples in the SharePoint, @antoinemerle can post the NetCDF in the SharePoint and compare output to the NetCDF.
Teams SharePoint directory: https://wmoomm.sharepoint.com/:f:/s/wmocpdb/EnqK9Y2bfGxPnXNM_yrOq5gBJrfprspEPKpXr7YVIivSbQ?e=lvTWvU
(post to 'documentation' folder)
Hi @amilan17
Table B 21 already has a descriptor for ASCAT sigma-0 usability (021159), but the data width is 2 bits instead of 3. Is it possible to use the existing descriptor instead of creating another one with the same name?
MERLE : For that case the code table are a bit different and our new one is more accurate one (according to me)
Flag tables : some of the ICI and MWI flag tables are almost identical -- does it make sense to combine them into one table?
MERLE : Almost identical but not identical, Those are still different instruments with different meanings.
BUFR Table D 10 : "008098, Source of temperature measurement, Cancel significance (15)" I wonder if this is correct, because code figure 15 is set to "Missing" in table 008098.
MERLE : 15 means missing which means also cancel. I mean this is the way we did it the past (I can confirm this info with Simon)
"10,Vertical sounding sequences (satellite data),310081,(Microwave Imager Data (level 1B)),,117003,Replicate 17 descriptors 3 times 333,,,,Operational" Is "333" in the element name a typo?
MERLE : It was a typo, I already corrected after your message
The element names of data description operators should be the same as the operator name in BUFR Table C and the details go into the element description column. Can you update these? 201YYY == Change data width 202YYY == Change scale 207YYY == Increase scale, reference value and data width for example: "20100, Cancel change of width, " should be "20100, Change data width, Cancel"
MERLE : for that particular comment, I did not understand it @amilan17 : please can you give me more information, I am willing to correct it
@antoinemerle
Thank you for your thorough feedback. The FXY sequences that begin with 201, 202 and 207 have predefined element names. The requested change is purely editorial, makes the text consistent and doesn't change the meaning. Below is a table with some detailed examples with the crossed out text replaced by the following line. You can also do a simple filter on the tables in the GitHub browser wiindow to see how these types of fields are written for other BUFR sequences. I hope this makes more sense, but I'm happy to explain more on Teams if you would like.
FXY2 | ElementName_en | ElementDescription_en |
---|---|---|
~201000~ | ~Cancel change of width~ | |
201000 | Change data width | Cancel |
~202000~ | ~Cancel change of scale~ | |
202000 | Change scale | Cancel |
~207003~ | ~Increase scale, reference value and data width (+3)~ | |
207003 | Increase scale, reference value and data width |
Dear @amilan17 , as promised :
Here are the new product for MWS and SCA in tinier part.
Each file is containing 1
BUFR message of 10
scans, so each file is contains 10
scans.
I also attached the netCDF used for encoding as ref.
PS : I tried to upload but it did not work with all the files so please at the moment find : for_WMO_lighter.zip
PS 2 : I updated the text for the cancel description : 3c113e2
@marijanacrepulja @SibylleK Will you be able to validate the sample data before Friday? Thanks!
The provided BUFR examples could be read by the DWD BUFR software. I uploaded the BUFR and the DWDoutput in the SharePoint documents under a issue136-NewEntries4EPS-SG folder.
I can't find the netCDFs. For comparison and check of the output some other outputs are needed. Maybe @marijanacrepulja is able to compare the DWD outputs with the output of eccodes, which would be sufficient for the technical validation. I can't judge, whether the values are correct. Maybe I get some comments of my colleagues.
Regarding some values of Flag tables, the encoding seems to be not correct, as the last bit is often set, which should not be. But this is not an obstacle for the validation.
@SibylleK @antoinemerle I made some editorial changes to element names and descriptions. Can you please double check that I didn't lose/change any meanings? (see just commit above)
Greetings @amilan17 and @SibylleK ,
Regarding amilan17's commit : I have reviewed the necessary commit and made some minor comments in the commits section.
Regarding the test data: You should now find the folder "MWS_and_SCA_and_the_netCDF_ref.zip" in the SharePoint. This folder contains the following:
Please confirm that you have received and have access to all necessary files. If there are any issues or missing documents, please let me know.
Thanks for your support , let me know if you need anything else
@amilan17 @antoinemerle @SibylleK
I was able to decode all BUFR examples, and when I compared the results to those provided by Sibylle, the values were identical. I can't examine the messages in depth because there are no corresponding netCDF files for each BUFR sample. As a result, I believe the proposed new descriptors and sequences are technically valid.
@marijanacrepulja Thank you.
@marijanacrepulja Thanks a million for this last review.
Also : @amilan17 , @SibylleK and @marijanacrepulja Thanks for the hard work and all the time everyone invested in the review of this long request. Happy to help in any case. 🚀
@antoinemerle Can you please update this branch with the edit needed? When ready please open a PR to merge this branch into FT2023-1 branch.
@amilan17 @SimonElliottEUM @antoinemerle
In the BUFR Template 310082 there is a difference between a branch and a proposal related to replications
Proposal
0 33 109 | MWS overall quality flags | 1 16 024 | Repeat 16 descriptors 24 times | 0 05 042 | Channel number | 1 02 004 | Repeat 2 descriptors 4 times | 0 05 079 | Band number
Git branch 033109,MWS overall quality flags 18024,Repeat 18 descriptors 24 times, 005042,Channel number 104004,Repeat 4 descriptors 4 times 005079,Band number
@SimonElliottEUM @antoinemerle Could you please confirm which of the entries is correct?
Many thanks
Hi @marijanacrepulja ,
The correct one is well the git branch. No action is needed on the code or repo
I should have updated the proposal when we changed the git branch, I will update the proposal according to what we pushed. I apologize for the inconvenience that it brought.
So it is completely correct is as it is in the branch
:
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,118024,Replicate 18 descriptors 24 times,,,,Operational
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,005042,Channel number,,,,Operational
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,104004,Replicate 4 descriptors 4 times,,,,Operational
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,005079,Band number,,,,Operational
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,202130,Change scale,Add 2 to descriptor scale,,,Operational
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,002154,Satellite channel band width,,,,Operational
10,Vertical sounding sequences (satellite data),310082,(Microwave Sounder Data (level 1B)),,202000,Change scale,Cancel,,,Operational
The very first initial proposal for MWS on this particular part of the sequence was
code | description |
---|---|
1 17 024 | Repeat 17 descriptors 24 times |
0 05 042 | Channel number |
0 40 192 | Satellite channel band width (first band) |
0 40 193 | Satellite channel band width (second band) |
0 40 194 | Satellite channel band width (third band) |
0 40 195 | Satellite channel band width (fourth band) |
But during the :
we made some changes to this part and we moved to the following sequence :
code | descr |
---|---|
1 18 024 | Repeat 18 descriptors 24 times |
0 05 042 | Channel number |
1 04 004 | Repeat 4 descriptors 4 times |
0 05 079 | Band number |
2 02 130 | Change scale (from -8 to -6) |
0 02 154 | Satellite channel band width |
2 02 000 | Change scale (reset to -8) |
the following was an intermediate state :
0 33 109 | MWS overall quality flags |
1 16 024 | Repeat 16 descriptors 24 times |
0 05 042 | Channel number |
1 02 004 | Repeat 2 descriptors 4 times |
0 05 079 | Band number
Initial request
This document proposes new BUFR entries for the following products : MWI, ICI, SCA, IAS 1, MWS. This entries correspond to the instruments embeded for EPS-SG mission
Amendment details
New table D entries
3 10 080
3 10 081
3 10 082
3 10 083
3 10 084
3 10 085
3 10 086
ICI
MWI
MWS
3 10 082
" Microwave Sounder Data (level 1B)" to BUFR Table D: Table referencesSCA SZF
3 10 083
"Metop-SG Scatterometer (SCA), Sigma zero full resolution level 1B (SZF)" to BUFR Table D Table referencesSCA SZR
3 10 084
: Metop-SG Scatterometer (SCA), Sigma zero resampled level 1B (SZR) : Table referencesIASI-NG L1C RAD
3 10 085
"IASI-NG L1C (Radiances)" to BUFR Table D : Table referencesIASI-NG L1D PCS
3 10 086
"IASI-NG L1D (Principle Component Scores)" to BUFR Table D : Table referencesNew entries in Table B :
Add the following elements to BUFR Table B :
New entries in existing code and flag table
New flag tables and related code
Comments
No response
Requestor(s)
EUMETSAT : Simon Elliott Antoine MERLE
Stakeholder(s)
ECMWF WMO ECCODES
Publication(s)
New entries in : Table B New entries in : Table D New entries in : Flag Table New entries to existing flag table
Expected impact of change
MEDIUM
Collaborators
EUMETSAT scientists
References
No response
Validation
No response