[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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