Giter Club home page Giter Club logo

Comments (12)

sebvi avatar sebvi commented on August 11, 2024

@wmo-im/tdcf : any feedback would be much appreciated!

from grib2.

efucile avatar efucile commented on August 11, 2024

Do we also need a parameter for the departure level? With the definition of the level I can have a field providing the value of the highest value of CAPE, but it might be important to know at which level it is. I see two fields one with the value of CAPE at the "Departure level of the most unstable parcel of air (MUDL)" and one with the level (model level number) for that value of CAPE

from grib2.

sebvi avatar sebvi commented on August 11, 2024

Yes we are already producing a CAPE parameter (and a CIN parameter) at each model level, this is how the most unstable CAPE is computed: CAPE is computed for all model level and at each grid point the highest value a CAPE is retained.

We will produce a CAPE50 (and CAPE100) which is calculated this way: A mean CAPE is computed between surface and a level differing by 50hPa (and 100hPa) from the surface. I am planning to ecode these this way:

Discipline=0
Category=7
Number=6
First fixed surface = 1
First scale factor=missing
First scaled value=missing
Second fixed surface = 108
Second scale factor=0
Second scaled value=50

although I don't know how to specify that the layer represented by surface to P0-P=50 is an average, not an integration, a max, a min, or anything else. All the statistical transformations are specific to Time, I am not aware of a way to specify this for an horizontal grid and a vertical column.

from grib2.

tomkralidis avatar tomkralidis commented on August 11, 2024

As discussed with our subject matter experts here at MSC/CCMEP, we are fine with supporting this field as part of our model output for future implementation.

from grib2.

tomkralidis avatar tomkralidis commented on August 11, 2024

Note we are also looking into CAPE and CIN and happy to bring in our subject matter experts to discus further.

from grib2.

SibylleK avatar SibylleK commented on August 11, 2024

I got comments from our research colleagues. They support the proposal and they provide following comments with an extension of the proposal:

Comment I:
In FT2016-1 there already was the attempt of BoM (Weiqing Qu) to establish "air parcel definitions" in Code Table 4.5. The proposal was not accepted mainly for being too prescriptive (over-specifing of thresholds and layer thicknesses).

Comment II:
DWD CAPE and CIN products destinguish between "most unstable air parcel" and a "mixed layer parcel" with local level definitions. Therefore DWD supports this proposal and wants to extend it: in addition to the "most unstable parcel", we like to define the "mixed layer parcel" and accordingly the corresponding departure level for the determination of mixed layer CAPE and CIN. In the mean time Sebastien came over with definition of CAPE50 and CAPE100; CAPE50 seems to be similar to DWDs mixed layer CAPE. So our first proposal with dimensionless "18" is changed to unit "Pa" to be able to distinguish between ECMWF CAPE50 and CAPE100 and to overcome the missing "average over a layer".

New entry 18 in Code table 4.5

Octet Name Units Description
18 Departure level of a mixed layer parcel of air with specified layer depth Pa This represents the vertical level from which the mixed layer parcel of air starts rising. NOTE: A mixed layer parcel is a parcel of air from a (well-mixed) near-surface atmospheric layer of a specified depth, whose properties represent the mean conditions of the layer. The layer being averaged (mixed) extends from the surface to a depth defined by the level coding.

|

from grib2.

sebvi avatar sebvi commented on August 11, 2024

Dear @SibylleK , thank you for your coontribution. Do I understand correctly that if I associate a value of 50 to this new type of level 18, it means that my mixed air parcel is computed as the mean value of CAPE/CIN from surface to a difference from surface of 50hPa?
If yes, then I support this solution.

More generally for GRIB3, it would be better to have a way to specify if a layer is an average, an accumulation, etc. within that layer.

from grib2.

chenxiaoxia2019 avatar chenxiaoxia2019 commented on August 11, 2024

@sebvi Hi, Sebastien, I created a new branch for this issue. And I added entries 17 and 18 to the Code Table 4.5. Could you please check it? Thanks.

from grib2.

SebastianB2 avatar SebastianB2 commented on August 11, 2024

Dear colleagues,

Please find below a GRIB file (zipped for uploading) which might serve as one example for the newly proposed fixed-surface types.
It contains two messages:
1st a constant (nonsensical) field of convective available potential energy for an air parcel with the mean properties of a near-surface layer of thickness 50 hPa. Its DWD short name is "CAPE_ML" and it probably corresponds to "CAPE50" of ECMWF mentioned by Sebastien above.
2nd a constant (nonsensical) field of convective inhibition for the most unstable air parcel with short name "CIN_MU". The meaning of this product is probably the same as ECMWF's "MUCIN" (see above).
At the moment the two products are coded at DWD using local definitions for two fixed-surface types:
"192 ML start Level of mixed layer parcel" and "193 MU start level of most unstable parcel".
Both could be replaced by the newly proposed types 17 and 18 as shown with the GRIB file below.

We used ecCodes (version 2.14.1) to interpret the GRIB file.
A short overview of the metadata is shown in grib_ls_of_test_new_levelType_17_and_18.pdf below (it's the output of the command: grib_ls -P levelType:l,levelType:s test_new_levelType_17_and_18.grb),
followed by a complete list of the metadata in grib_dump_of_test_new_levelType_17_and_18.pdf (the output of grib_dump -O test_...grb).
We extended our local definitions for ecCodes by the newly proposed fixed-surface types in order to get the desired interpretation by grib_ls and grib_dump.
Please let us know if there are questions, comments or remarks.

test_new_levelType_17_and_18.grb.zip
grib_ls_of_test_new_levelType_17_and_18.pdf
grib_dump_of_test_new_levelType_17_and_18.pdf

from grib2.

sebvi avatar sebvi commented on August 11, 2024

@chenxiaoxia2019 the branch looks ok to me as well.

I could also decode the samples provided by DWD.

from grib2.

amilan17 avatar amilan17 commented on August 11, 2024

SUMMARY: Add entries, 17 & 18, to code table 4.5.

from grib2.

amilan17 avatar amilan17 commented on August 11, 2024

Approved by FT-2020-2.

from grib2.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.