NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: [netcdf-java] Reading GRIB2 levels data

HI Nikolas:

So I dont see any such grib record in the file. I would expect discipline =
0, category = 3, parameter = 6 according to the Note. There is likely some
formula we need to know also, using the level values (32-33, 33-34, etc).
You might want to contact NCEP to see if you can track that down.

I also see that I dont in fact deal with this case, although some of the
mechanism for doing so is done(VExplicitField).

So, Im sorry I cant help you. If you do locate the missing grib record and
the correct formula, send it along and ill have a look at it.

John



On Wed, Dec 7, 2016 at 6:05 AM, Dahn, Nikolas <
nikolas.dahn@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Thank you kindly for your support. I have uploaded a file to the following
> URL:
> https://mega.nz/#!JkI0DIbJ!-P7VqflJJ2jnPDGA3BB158IthLEGojT756xPEF2wgeQ
>
> The following variables use the generalized height coordinates:
> - Temperature
> - Pressure
> - u-component_of_wind
> - v-component_of_wind
>
> Up till now I was not able to find the corresponding 3D-Grib-Message, but
> I'm not sure how to look for it either. I am happy with my solution for
> now, but I suspect there might be more data hidden somewhere (?).
>
> Thanks,
> Nikolas
>
> PS: John, thanks for the hint at the 5.0 branch. I wasn't aware of it. I
> will check it out in the near future.
>
>
> ------------------------------
> *Von:* Antonio S. Cofiño [antonio.cofino@xxxxxxxxx]
> *Gesendet:* Dienstag, 6. Dezember 2016 16:08
> *An:* John Caron; Dahn, Nikolas
> *Betreff:* Re: [netcdf-java] Reading GRIB2 levels data
>
> Dahn, if you want I can provide you a sftp where you can put the file,
> and make it available to everyone via HTTP. (or restricted what you
> prefer).
>
> Just sent me your SSH public key
>
> Antonio
>
>
> --
> Antonio S. Cofiño
> Associate Professor and Researcher
> Grupo de Meteorología de Santander
> Dep. of Applied Mathematics and Computer Sciences
> Universidad de Cantabria (Spain)
>
> Academic Visitor
> National Centre for Atmospheric Science
> Department of Meteorology
> School of Mathematical, Physical and Computational Sciences
> University of Reading (UK)
> http://antonio.cofino.es
>
> On 06/12/16 14:33, John Caron wrote:
>
> Hi Nikolas:
>
> 1. The best version of the library to work on with GRIB is 5.0.
>
> https://www.unidata.ucar.edu/software/thredds/v5.0/netcdf-
> java/documentation.html
>
> 2. Generalized Vertical Height Coordinate (see Note 4)
>
> The definition of a generalized vertical height coordinate implies the
> absence of coordinate values in section 4 but the presence of an external
> 3D-GRIB message that specifies the height of every model grid point in
> meters (see Notes for section 4), i.e., this GRIB message will contain the
> field with discipline = 0, category = 3, parameterm = 6 (Geometric height).
>
> So the code has to search though the file to look for another GRIB record
> ("an external 3D-GRIB message") to find the coordinates. So the PDS does
> not have the information.
>
> There are some heuristics somewhere to do this. Ill have to dig around for
> where that is, but (assuming it finds it) it should create the correct
> coordinate system at the GridDataset layer.
>
>
> 3. To help you any further I will need a copy of the file. Can you put on
> ftp or dropbox or something?
>
> Regards,
> John
>
> On Mon, Dec 5, 2016 at 9:50 AM, Dahn, Nikolas <nikolas.dahn@iosb-ast.
> fraunhofer.de> wrote:
>
>> I found a fix and a way to apply it as a temporary hack. Basically what
>> happens is the following:
>> - In Grib2CollectionBuilder.Grib2Rectilyser.make unique coordinate
>> systems are built from the various PDS sections
>> - The PDS' data sections are collected into VariableBags
>> - To determine which coordinates are used the vertical height unit is
>> examined, among others
>> - This unit is (usually) provided by the Grib2Customizer (an
>> implementation of GribTables)
>> - The current implementation lacks a switch-case for code 150
>> (generalized vertical height) and the default mapping defines the unit as
>> 'null'
>> - From this it is determined that no vertical coordinate is present
>> - Thus the coordinate is missing and the builder builds the coordinate
>> system without the height coordinate
>> - In the end most of the data is missing because the later data sections
>> overwrite the earlier ones, as one of their distinguishing dimensions is
>> missing
>>
>> The fix is quite simple: all I did was adding case statements for code
>> 150 in Grib2Customizer.getVertUnit(int) and
>> Grib2Customizer.getLevelNameShort(int). A patch is attached below.
>>
>> For those who stumble over this and don't have access to a patched
>> version, you can derive a class from Grib2Customizer and override the two
>> offending methods. Then set a private variable of Grib2Customizer via
>> reflection like shown below. I recommend doing this in a static block.
>>
>>     Field f = Grib2Customizer.class.getDeclaredField("wmoStandardTable");
>>     f.setAccessible(true);
>>     f.set(null, MyGrib2Customizer.factory(0, -1, -1, -1, -1));
>>
>> Cheers,
>> ~
>>
>>
>> Patch:
>> ====
>> --- ucar/nc2/grib/grib2/table/Grib2Customizer.java.orig    2016-12-05
>> 17:44:09.663099300 +0100
>> +++ ucar/nc2/grib/grib2/table/Grib2Customizer.java.patched    2016-12-05
>> 17:45:16.147099300 +0100
>> @@ -408,6 +408,9 @@
>>        case 119:
>>          return new GribLevelType(code, "Pa", null, false); // ??
>>
>> +      case 150:
>> +        return new GribLevelType(code, "numeric", null, true);
>> +
>>        case 160:
>>          return new GribLevelType(code, "m", "sea level", false);
>>
>> @@ -505,6 +508,8 @@
>>          return "hybrid_pressure";
>>        case 120:
>>          return "pressure_thickness";
>> +      case 150:
>> +        return "generalized_vertical_height";
>>        case 160:
>>          return "depth_below_sea";
>>        case GribNumbers.UNDEFINED:
>>
>> _______________________________________________
>> NOTE: All exchanges posted to Unidata maintained email lists are
>> recorded in the Unidata inquiry tracking system and made publicly
>> available through the web.  Users who post to any of the lists we
>> maintain are reminded to remove any personal information that they
>> do not want to be made public.
>>
>>
>> netcdf-java mailing list
>> netcdf-java@xxxxxxxxxxxxxxxx
>> For list information or to unsubscribe, visit:
>> <http://www.unidata.ucar.edu/mailing_lists/>http://www.unidata.ucar.edu/
>> mailing_lists/
>>
>
>
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web.  Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> netcdf-java mailing listnetcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit: 
> http://www.unidata.ucar.edu/mailing_lists/
>
>
>
  • 2016 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: