Re: 20040625: GRIB problem in decoders-3.0.2 - bug?

NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.

On Fri, 25 Jun 2004, Unidata Support wrote:

>To: support@xxxxxxxxxxxxxxxx
>From: Arild Burud <Arild.Burud@xxxxxx>
>Subject: GRIB problem in decoders-3.0.2 - bug?
>Organization: UCAR/Unidata
>Keywords: 200406251028.i5PASJWb020515

Hi,
I recently installed decoders-3.0.2 on a new linux workstation, and
found a problem... It seems like the update described as "added
forecasttime variable to gribtocdl" may be involved in this.
I try to convert a grib file that contains "monthly mean" of a
parameter, this is stored according to the "grib standard" with flags
indicating this in the grib section one: Octet 21 = 123 (="average"),
octet 20 = 24 (="24 hour periods").

Hiya Arild,

Thanks again for the gribtocdl code. I wonder if version 3.0.0 had the
same problem as 3.0.2?  At first thought, I don't see how the
forecasttime variable could cause this problem but maybe there is a
dependancy that I over looked. I'll check it out.


Robb...
When I use gribtocdl and gribtonc I end up with a netCDF file that
contains two days of data, the first day contains only undefined values,
the second contains the data from the grib file. See extracts from
gribdump and ncdump below:

-----------------------------------------------------
                      Header : 1
          Originating Center : 98 (European Center for Medium-Range
Weather Forecasts - Reading)
                     Process : 122 (ECMWF model 122)
                        Grid : 255
              points in grid : 29040
                   Parameter : 34 (v)
                       Units : m/s
                  Level Type : Surface
              Reference Time : 2004/04/01:12:00
                   Time Unit : Hour
        Time Range Indicator : Special average Algorithm 3
                 Time 1 (P1) : 0
                 Time 2 (P2) : 24
        Decimal Scale Factor : 0
         Binary Scale Factor : -10
             Reference Value : 270.895752
               Minimum Value : 270.8958
              Number of Bits : 16
                BMS Included : TRUE
                GDS Included : TRUE
         IsInternationalGrid : FALSE
                GRIB Edition : 1
         Parameter Table Ver : 128
     GDS representation type : 0 (Latitude/Longitude)
           Number of columns : 240
              Number of rows : 121
            Number of points : 29040
                Kind of grid : rectangular
           GDS res/comp flag : 0x80
          GDS scan mode flag : 0
     GDS no. of vert. coords : 0
                      GDS Ni : 240
                      GDS Nj : 121
                     GDS La1 : 90.000000
                     GDS Lo1 : -178.500000
                     GDS La2 : -90.000000
                     GDS Lo2 : 180.000000
                      GDS Di : 1.500000
                      GDS Dj : 1.500000
                  grid values:
Row 0:
        271.4602 271.4602 271.4602 271.4602 271.4602 271.4602 271.4602
<snip>

------------------------------------------------------

<snip>
// global attributes:
                :record = "reftime, valtime" ;
                :history = "2004-06-25 09:38:49 - created by gribtocdl" ;
                :title = "Enter model definition here" ;
                :Conventions = "NUWG" ;
                :GRIB_reference = "Office Note 388 GRIB" ;
                :GRIB_URL = "http://www.nco.ncep.noaa.gov/pmb/docs/on388/"; ;
                :version = 0. ;
data:

  reftime = 107388, 107388 ;

  valtime = 107412, 107388 ;

  datetime
   "2004-04-01 12:00:00Z",
   "2004-04-01 12:00:00Z" ;

  valtime_offset = 24 ;

  forecasttime
   "2004-04-02 12:00:00Z",
   "" ;

<snip>
-----------------------------------------------------------

If I modify the gribfile so that the "Time 2 (P2)" is reset to zero, the
netCDF file comes out as expected, with only one date of data.

Seems likely that this problem is connected to the "valtime_offset"
calculation...

I you need the unmodified grib file used in this example, it is
available from http://noserc.met.no/34m20040400t1200.grib


Yours,
Arild Burud
--
---------------------------------------------------------------------
Arild.Burud@xxxxxx       System Developer          Tel.: +47 22963035
http://www.met.no                                  Fax.: +47 22963050
Norwegian Service Centre for Climate Modelling,  http://noserc.met.no
Norwegian Meteorological Institute,    PB 43 Blindern,    N-0313 Oslo
---------------------------------------------------------------------


--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.


==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================


  • 2004 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the decoders archives: