Parameter numbers in GRIB1/GRIB2

[pesei]

FLEXPART identifies different fields through parameter category, parameter number and level type. These are not always the same and have changed from GRIB1 to GRIB2, thus creating problems for reading sfc parameters in GRIB2.

Using shortName as identifier instead would (almost) solve this problem.

Furthermore, precipitation units have changed from m in GRIB1 to mm in GRIB2.

Adaption of gridcheck.f90 and gridcheck_nests.f90 would be desirable.

(based on input from Leo Haimberger)

[pasko]

Some comments:

1. As FLEXPART is using grib_api to read the gribmessages from file, I'm wondering why (in case of ECMWF) you are NOT using the edition independent GRIB API keys (​http://www.ecmwf.int/publications/manuals/d/gribapi/keys )! When using those keys no one needs to distinguish between GRIB1 and GRIB2!

2. Why is preciptation saved in GRIB2 Format? What is the purpose of conversion ? In MARS, only 3D-Parameters are retrieved in GRIB2, surface parameter still remains in GRIB1. So why is the conversion to GRIB2 done ?

Btw. preciptation did NOT change units ! (​http://www.ecmwf.int/publications/manuals/d/gribapi/param/filter=grib1/order=paramId/order_type=asc/p=1/search=precipitation/table=128/)

[pesei]

Replying to pasko:

1. As FLEXPART is using grib_api to read the gribmessages from file, I'm wondering why (in case of ECMWF) you are NOT using the edition independent GRIB API keys (​http://www.ecmwf.int/publications/manuals/d/gribapi/keys )!

As far as I understand, key is a general concept. Looking deeper (​http://www.ecmwf.int/publications/manuals/d/gribapi/keys/show/parameter/) I find

paramId	Unique identifier of the parameter. A parameter in different formats (grib1/grib2) is identified by the same ID.
shortName	Not unique. Different parameters can have the same short name.
name	Not unique. Different parameters can have the same name.

Is paramID what is presently used? If so, what are the problems? If not, shouldn't we use it?

2. Why is preciptation saved in GRIB2 Format? What is the purpose of conversion ? In MARS, only 3D-Parameters are retrieved in GRIB2, surface parameter still remains in GRIB1. So why is the conversion to GRIB2 done ?

Btw. preciptation did NOT change units ! (​http://www.ecmwf.int/publications/manuals/d/gribapi/param/filter=grib1/order=paramId/order_type=asc/p=1/search=precipitation/table=128/)

should be clarified by Leo.

[leohaim]

Replying to pesei,pasko

Indeed it seems better to use paramId instead of shortName. In earlier GRIB FORTRAN APIs one could not get paramId. This was likely also the reason why FLEXPART developers resorted to parametertype, parameternumber to identify fields. Even today, you will see that paramId is only output by grib_dump if fields are in GRIB1 format, whild
parametercategory and parameternumber are output if fields are in GRIB2 format.
However, if one specifies paramId in grib_ls, one gets paramID for both
GRIB1 and GRIB2. So I will give this a try.

Regarding precipitation: If one tries to convert convective precipitation
from GRIB1 into GRIB2, it is changed to parametername acpcp (liquid
convective precipitation) by grib_set. This parameter has units kg/m2.
So far I found no way to avoid that unless to leave the field in GRIB1.

There are two reasons why one would like all files in the same format:
1) IO Codes are easier to maintain
2) GRIB2 allows JPEG compression, which is slow but allows substantial file size
reductions. One may want to compress also the surface fields,
not only model level fields.

This should be enough reason to give users the choice to safely convert everything into GRIB2.

[dearn]

WIithin the CTBTO project (​https://www.flexpart.eu/wiki/FpCtbto) a new concept for easily dealing with grib1/2 using the Vtables (​https://www.flexpart.eu/wiki/fpvtable) concept has been implemented as a prototype.

It will be further exploited in following work witihn the same project to handle both GFS and ECMWF and simplify the calls and selection of the grib messages