Re: 20051206: Gempak to grib conversion of CED type grid

Kevin,

the generating process ID of the GFS model is 96
http://www.nco.ncep.noaa.gov/pmb/docs/on388/tablea.html
The subcenter should be 0. This will identify the grid
as NCEP's GFS model.

Most decoders do not care about a WMOHDR, which is only
used for broadcasting the data over the GTS.

The cpyfil value is used to specify a grid number for PDS octet 7,
otherwise, the value of 255 (gds defined will be used). It may be
that your proprocessing is specifically looking for the PDS octet 7
to specifically identify itself as #003 rather than 255. The
GRIB from NCEP would definitely have a value of 3 in octet 7.

Steve Chiswell
Unidata User Support

On Wed, 2005-12-07 at 12:12, Kevin Hill wrote:
> Steve,
> 
> Thanks for the quick reply. I guess I was under the impression that those
> values were either not necessary to set or were set by comparing to the
> cpyfil. In general the only parameters that I am unsure how to set are:
> 
> VERCEN
> WMOHDR
> 
> Do you have any idea of what those should be set to in order to replicate
> the values that are found in the gfs-avn 1 degree analysis? The data I am
> using is available at the following website:
> 
> http://nomads.ncdc.noaa.gov/data/gfs-avn-hi/
> 
> Thanks, I really appreciate your help.
> 
> Kevin
> 
> 
> > Kevin,
> >
> > You have left most of the fields in GDGRIB blank.
> >
> > You have to specify the values of the PDS block to identify the
> > grib bits that are needed to identify the model center, version,
> > etc which will be used to identify the grib.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >
> > On Wed, 2005-12-07 at 11:20, Kevin Hill wrote:
> >> Steve and others,
> >>
> >> I apologize for not being very specific with my question! I am aware
> >> that
> >> I need to use gdgrib to convert from Gempak to grib. For my work I am
> >> taking Gempak grids and modifying them using a fortran program and then
> >> trying to take those Gempak files and convert them back to grib. When
> >> doing that, I used a gdgrib script, but when trying to use those grib
> >> files in WRFSI I receive errors. Therefore, I was not sure if the error
> >> was due to my alterations of the original grid using fortran or if it
> >> was
> >> due to the GDGRIB conversion script I ran.
> >>
> >> In order to test that, I tried to modify 1 grib file that WRFSI was able
> >> to process. I took that grib file and converted it to Gempak using
> >> dcgrib.
> >> Next I used GDGRIB to take one grid from that Gempak file and place it
> >> back into the grib file. After doing this, WRFSI gave an error.
> >> Therefore,
> >> I concluded that something was wrong with the script I was using to
> >> convert from Gempak to grib.
> >>
> >> The previous problems I have mentioned have been found when trying to
> >> manipulate a grid that is a global 1 degree analysis (Cylindrical
> >> Equidistant projection). I tried the previous procedure using a grid
> >> with
> >> a mercator projection and I was able to have success. Therefore, I felt
> >> that the problem with the GDGRIB conversion process must be due to the
> >> CED
> >> projection type, and was wondering if something in GDGRIB needed to be
> >> set
> >> differently due to the fact that the grid is CED.
> >>
> >> Here is the script I used to take 1000 mb height out of a Gempak file
> >> and
> >> write it back into the grib file.
> >>
> >> gdgrib << endin
> >> gdfile  = "gfs-avn-hi_3_20040911_0000_000.gem"
> >> gfunc   = hght
> >> gdattim = "040911/0000F000"
> >> glevel  = 1000
> >> gvcord  = pres
> >> gbtbls  = wmogrib131.tbl
> >> gbfile  = "gfs-avn-hi_3_20040911_0000_000.grb"
> >> vercen  =
> >> pdsval  =
> >> precsn  =
> >> wmohdr  =
> >> cpyfil  = "gfs-avn-hi_3_20040911_0000_000.gem"
> >> proj    =
> >> grdarea =
> >> kxky    =
> >> r
> >>
> >> endin
> >>
> >> Here, the gfs-avn-hi_3_20040911_0000_000.grb file is a grib file that I
> >> downloaded from Nomads. The gfs-avn-hi_3_20040911_0000_000.gem file is a
> >> Gempak file created form the gfs-avn-hi_3_20040911_0000_000.grb grib
> >> file
> >> using dcgrib. All I am trying to do is take 1 grid from the Gempak file
> >> and write it back into the grib file. This should lead to a grib file
> >> that
> >> is identical to the original. However, after doing that, WRFSI is no
> >> longer able to run.
> >>
> >> Overall, it appears that converting the CED grib file to GEMPAK using
> >> dcgrib and then converting back from GEMPAK to grib using gdbrib somehow
> >> leads to a grib file that is different than the original and will no
> >> longer be able to work in wrfsi. I had thought that doing this type of
> >> conversion would yield a grib file that was identical to the original
> >> and
> >> would be able to be processed by WRFSI. (Note that this process did work
> >> when I did the same procedure using a grid that was a mercator
> >> projection
> >> type).
> >>
> >> Does anyone have any ideas as to why the CED grid would experience this
> >> problem? Since I am setting cpyfil to the gempak file created from the
> >> original grib file using dcgrib I figured the necessary parameters would
> >> be set correctly; or maybe I am wrong and something else needs to be
> >> set.
> >>
> >> Thanks for any assistance!
> >>
> >> Kevin
> >
> 
> 
> Kevin Hill
> Graduate Teaching/Research Assistant
> address@hidden
> Office: Research 3, Room 100
>