[netCDFJava #RXE-920332]: Grib2NetCDF incorrectly converting time durations

Hi Edward:

From this page:

http://www.weatheroffice.gc.ca/grib/what_is_GRIB_e.html

ive decided that they are using NCEP (center 7) tables, so im going to use 
those.

thanks,
John

> I can't recall exactly which field I attached before, but I think it may have 
> been the DSWRF variable which can be found at:
> 
> http://dd.weatheroffice.gc.ca/ensemble/naefs/grib2/raw/00/006/CMC_naefs-geps-raw_DSWRF_SFC_0_latlon1p0x1p0_2011111400_P006_allmbrs.grib2
> 
> The details of the grib2 params for each variable can actually be found here:
> http://www.weatheroffice.gc.ca/grib/GEPS_HR/GEPS_NAEFS_latlon1p0x1p0_PNONZERO_MBRZERO_e.html
> 
> Hopefully that's helpful.
> 
> -Edward
> 
> -----Original Message-----
> From: Unidata netCDF Java Support [mailto:address@hidden]
> Sent: Tuesday, 15 November 2011 4:45 a.m.
> To: Edward Glen
> Cc: address@hidden
> Subject: [netCDFJava #RXE-920332]: Grib2NetCDF incorrectly converting time 
> durations
> 
> > Hi John,
> >
> > Thanks for the response - Is there a list to subscribe to for notification 
> > of the 4.3 alpha release?
> 
> join netcdf-java from this page:
> 
> http://www.unidata.ucar.edu/support/index.html#mailinglists
> 
> >
> > As for the 4-192 parameter - I'm not certain as to precisely you're 
> > referring to (my grib2 skills are a still developing), but I think it 
> > perhaps should be the ensemble member?
> 
> it is an ensemble member, but we dont know what the parameter is. it looks 
> like some kind of solar radience, judging from the values of the data.
> 
> > As for a contact person, I've been dealing with Miguel Tremblay 
> > <address@hidden> there - not sure if he's the right person or if he can 
> > refer you to the correct person.  They don't appear to have any local 
> > tables available for download on their website that I can find.
> 
> where did this data come from ?
> 
> >
> > -Edward
> >
> > -----Original Message-----
> > From: Unidata netCDF Java Support
> > [mailto:address@hidden]
> > Sent: Friday, 11 November 2011 10:01 a.m.
> > To: Edward Glen
> > Cc: address@hidden
> > Subject: [netCDFJava #RXE-920332]: Grib2NetCDF incorrectly converting
> > time durations
> >
> > Hi Edward:
> >
> > 1) This bug is fixed in version 4.3, which will have an alpha release soon.
> >
> > 2) Grib2Netcdf is deprecated and uses the 4.2 classes, see this page on 
> > writing files:
> >
> > http://www.unidata.ucar.edu/software/netcdf-java/reference/Cookbook.ht
> > ml#writeClassic
> >
> > 3. We dont have tables for this parameter 0-4-192 from this local table:
> >
> > Center        = (54) Montreal (RSMC)
> > SubCenter     = (0) null
> > Master Table  = 4
> > Local Table   = 0
> >
> > You may note that version 4.2 assigned an incorrect parameter from NCEP 
> > (center 7) tables. Do you have any information on what it should be, or who 
> > to contact to get that table?
> >
> > thanks!
> >
> > John
> >
> > > Full Name: Edward Glen
> > > Email Address: address@hidden
> > > Organization: MetService New Zealand Package Version: toolsUI-4.2
> > > Operating System: Ubuntu 10.04
> > > Hardware:
> > > Description of problem:
> > >
> > > I used the ucar.nc2.iosp.grib.Grib2Netcdf converter to convert the
> > > attached .grib2 file to NetCDF (result also attached).
> > >
> > > The wgrib2 summary for the grib2 file is:
> > >
> > > 1:0:d=2010110600:var discipline=0 center=54 local_table=0 parmcat=4
> > > parm=192:surface:0-6 hour acc fcst:MM-ENS=10
> > >
> > > indicating that the duration for the grib record is 0-6 hour.
> > >
> > > Converted to NetCDF, the time dimension becomes:
> > >
> > > int time(time) ;
> > > time:long_name = "forecast time for (1 hour intervals)" ; time:units
> > > = "hour since 2010-11-06T00:00:00Z" ; time:bounds = "time_bounds" ;
> > > int time_bounds(time, bounds_dim) ; time_bounds:long_name = "bounds
> > > for time" ; time_bounds:units = "hour since 2010-11-06T00:00:00Z" ;
> > >
> > > time_bounds =
> > > 0, 1 ;
> > >
> > > time = 1 ;
> > >
> > > Which I read as meaning 0 to 1 hours, not 0 to 6 hours.
> > >
> > > Am I misunderstanding this or is the converter not correctly taking
> > > the size of the duration into account?
> > >
> > > Thanks,
> > > -Edward
> > >
> > >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: RXE-920332
> > Department: Support netCDF Java
> > Priority: Normal
> > Status: Open
> >
> >
> 
> 
> Ticket Details
> ===================
> Ticket ID: RXE-920332
> Department: Support netCDF Java
> Priority: Normal
> Status: Open
> 
> 
> I can't recall exactly which field I attached before, but I think it may have 
> been the DSWRF variable which can be found at:
> 
> http://dd.weatheroffice.gc.ca/ensemble/naefs/grib2/raw/00/006/CMC_naefs-geps-raw_DSWRF_SFC_0_latlon1p0x1p0_2011111400_P006_allmbrs.grib2
> 
> The details of the grib2 params for each variable can actually be found here:
> http://www.weatheroffice.gc.ca/grib/GEPS_HR/GEPS_NAEFS_latlon1p0x1p0_PNONZERO_MBRZERO_e.html
> 
> Hopefully that's helpful.
> 
> -Edward
> 
> -----Original Message-----
> From: Unidata netCDF Java Support [mailto:address@hidden]
> Sent: Tuesday, 15 November 2011 4:45 a.m.
> To: Edward Glen
> Cc: address@hidden
> Subject: [netCDFJava #RXE-920332]: Grib2NetCDF incorrectly converting time 
> durations
> 
> > Hi John,
> >
> > Thanks for the response - Is there a list to subscribe to for notification 
> > of the 4.3 alpha release?
> 
> join netcdf-java from this page:
> 
> http://www.unidata.ucar.edu/support/index.html#mailinglists
> 
> >
> > As for the 4-192 parameter - I'm not certain as to precisely you're 
> > referring to (my grib2 skills are a still developing), but I think it 
> > perhaps should be the ensemble member?
> 
> it is an ensemble member, but we dont know what the parameter is. it looks 
> like some kind of solar radience, judging from the values of the data.
> 
> > As for a contact person, I've been dealing with Miguel Tremblay 
> > <address@hidden> there - not sure if he's the right person or if he can 
> > refer you to the correct person.  They don't appear to have any local 
> > tables available for download on their website that I can find.
> 
> where did this data come from ?
> 
> >
> > -Edward
> >
> > -----Original Message-----
> > From: Unidata netCDF Java Support
> > [mailto:address@hidden]
> > Sent: Friday, 11 November 2011 10:01 a.m.
> > To: Edward Glen
> > Cc: address@hidden
> > Subject: [netCDFJava #RXE-920332]: Grib2NetCDF incorrectly converting
> > time durations
> >
> > Hi Edward:
> >
> > 1) This bug is fixed in version 4.3, which will have an alpha release soon.
> >
> > 2) Grib2Netcdf is deprecated and uses the 4.2 classes, see this page on 
> > writing files:
> >
> > http://www.unidata.ucar.edu/software/netcdf-java/reference/Cookbook.ht
> > ml#writeClassic
> >
> > 3. We dont have tables for this parameter 0-4-192 from this local table:
> >
> > Center        = (54) Montreal (RSMC)
> > SubCenter     = (0) null
> > Master Table  = 4
> > Local Table   = 0
> >
> > You may note that version 4.2 assigned an incorrect parameter from NCEP 
> > (center 7) tables. Do you have any information on what it should be, or who 
> > to contact to get that table?
> >
> > thanks!
> >
> > John
> >
> > > Full Name: Edward Glen
> > > Email Address: address@hidden
> > > Organization: MetService New Zealand Package Version: toolsUI-4.2
> > > Operating System: Ubuntu 10.04
> > > Hardware:
> > > Description of problem:
> > >
> > > I used the ucar.nc2.iosp.grib.Grib2Netcdf converter to convert the
> > > attached .grib2 file to NetCDF (result also attached).
> > >
> > > The wgrib2 summary for the grib2 file is:
> > >
> > > 1:0:d=2010110600:var discipline=0 center=54 local_table=0 parmcat=4
> > > parm=192:surface:0-6 hour acc fcst:MM-ENS=10
> > >
> > > indicating that the duration for the grib record is 0-6 hour.
> > >
> > > Converted to NetCDF, the time dimension becomes:
> > >
> > > int time(time) ;
> > > time:long_name = "forecast time for (1 hour intervals)" ; time:units
> > > = "hour since 2010-11-06T00:00:00Z" ; time:bounds = "time_bounds" ;
> > > int time_bounds(time, bounds_dim) ; time_bounds:long_name = "bounds
> > > for time" ; time_bounds:units = "hour since 2010-11-06T00:00:00Z" ;
> > >
> > > time_bounds =
> > > 0, 1 ;
> > >
> > > time = 1 ;
> > >
> > > Which I read as meaning 0 to 1 hours, not 0 to 6 hours.
> > >
> > > Am I misunderstanding this or is the converter not correctly taking
> > > the size of the duration into account?
> > >
> > > Thanks,
> > > -Edward
> > >
> > >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: RXE-920332
> > Department: Support netCDF Java
> > Priority: Normal
> > Status: Open
> >
> >
> 
> 
> Ticket Details
> ===================
> Ticket ID: RXE-920332
> Department: Support netCDF Java
> Priority: Normal
> Status: Open
> 
> 


Ticket Details
===================
Ticket ID: RXE-920332
Department: Support netCDF Java
Priority: Critical
Status: Closed