Thank you ever so much for looking into this!
As I posted earlier, adding entries for the Generalized Vertical Height (150)
in Grib2Customizer allows the system to recognize the 4th dimension. For my use
case this is sufficient.
It seems like for these files the level values are further specified by some
(external) table which links them to pressures. If you are interested I will
let you know when I get the details.
Thanks again!
Nikolas
________________________________
Von: John Caron [jcaron1129@xxxxxxxxx]
Gesendet: Samstag, 10. Dezember 2016 02:21
An: Dahn, Nikolas
Cc: Antonio S. Cofiño; netcdf-java@xxxxxxxxxxxxxxxx
Betreff: 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<mailto: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<mailto: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@xxxxxxxxxxxxxxxxxxxxxx<mailto:nikolas.dahn@xxxxxxxxxxxxxxxxxxxxxx>>
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<mailto: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 list
netcdf-java@xxxxxxxxxxxxxxxx<mailto:netcdf-java@xxxxxxxxxxxxxxxx>
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
