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

Re: Unidata 64-bit N-AWIPS binary question

Fanyou,

If you are using dcgrib2 to convert GRIB to GEMPAK format, set the
maximum number of grids in the file with "-m 500".

Ifg you are using NAGRIB, set MAXGRD in the parameter settings.

Steve Chiswell
Unidata User Support



On Mon, 2007-04-09 at 14:51 -0500, Fanyou Kong wrote:
> I'm looking how to change that.
> 
> Fanyou
> 
> David Bright wrote:
> > Fanyou,
> > 
> > This could be it.  The NCEP version of GEMPAK has a maximum header/grid 
> > size of 4999.  Your gempak file has a maximum size of 9999 grids; it 
> > could be the ensemble tools are trying to read the entire header block, 
> > and our maxgrd size is 4999.   Can you change your code that creates and 
> > writes the gempak files so maxgrd < 5000?   In fact, right now we only 
> > have 52 grids in each member file, so maxgrd = 500 or so should be 
> > plenty sufficient.
> > 
> > David
> > 
> > Fanyou Kong wrote:
> > 
> >> David,
> >> Do you know what maximum number of headers NCEP GEMPAK uses? We can 
> >> first test
> >> this.
> >>
> >> Fanyou
> >>
> >>
> >> Steve Chiswell wrote:
> >>
> >>> Gregg,
> >>>
> >>> The general difference in my release is I increase the maximum number of
> >>> headers in the distribution (to 30,000) so it is possible to create a
> >>> grid file using the Unidata
> >>> distribution with more grids in it than the NCEP distribution would be
> >>> able to handle.
> >>> The solution there is simply to use hourly files with maximum number of
> >>> grids
> >>> that the NCEP distribution can handle.
> >>>
> >>> On my dcgrib2 decoder I provide, I allow for storage of GRIB2 products
> >>> using GRIB2 packing which makes the products much smaller and the
> >>> decoder faster than if
> >>> the data had to be unpacked and repacked into GRIB1. That is
> >>> controllable by a
> >>> decoder flag.
> >>>
> >>> The WRF wrfpost I have creates GRIB1 output, so the above shouldn't
> >>> be an issue (unless they are creating GRIB2 format  files for decoding
> >>> into GEMPAK....then they can either tell dcgrib2 to use GRIB1 packing,
> >>> or use nagrib2 for decoding to GEMPAK files).
> >>>
> >>> I don't make 32/64 bit modifications to the distribution, but do provide
> >>> both
> >>> 32 and 64 bit executables for Linux. The 64 bit environment is
> >>> that which NCEP provides, and ensures that the pr/ library functions
> >>> return
> >>> the correct size arguments.
> >>>
> >>> Can you provide any infomation about the files, eg number of grids
> >>> (GDINFO output)
> >>> in the GEMPAK file, and/or how they are creating GEMPAK files?
> >>> Steve CHiswell
> >>> Unidata User Support
> >>>
> >>>
> >>> On Mon, 2007-04-09 at 12:05 -0500, Gregory Grosshans wrote:
> >>>
> >>>> Hi Steve,
> >>>>
> >>>> The Storm Prediction Center and the University of Oklahoma is
> >>>> interested in what differences exist between the Unidata 64-bit Linux
> >>>> executables and the Unidata Linux executables compared to the NCEP
> >>>> release.
> >>>>
> >>>> OU is running a 10 member 4km WRF storm scale ensemble (x=753 ,y=663)
> >>>> on an AMD 64-bit supercomputer creating NetCDF output.  OU then uses a
> >>>> program to convert the NetCDF output into GEMPAK grids using the 64bit
> >>>> Gempak Linux executables.  When the SPC receives the GEMPAK grids from
> >>>> OU/supercomputer the NCEP NMAP2 core dumps when using the ensemble
> >>>> functionality of NMAP2 (i.e. datatype, mod_res.tbl, etc.).  The NCEP
> >>>> NMAP2 will display individual WRF output gempak files created on the
> >>>> supercomputer.
> >>>>
> >>>> SPC has taken the GEMPAK files from the supercomputer and used NCEP
> >>>> GDCFIL and GDMOD to create a new GEMPAK file and copy over the
> >>>> Supercomputer GEMPAK contents to the NCEP 32-bit GEMPAK file.  Then
> >>>> NCEP NMAP2 successfully displays the data using the ensemble 
> >>>> functionality.
> >>>>
> >>>> We're wondering if this may be a 32 vs 64-bit issue, or NCEP vs
> >>>> Unidata GEMPAK issue, or both?  Any information you can provide on
> >>>> what differences may exist between the Unidata release and NCEP is
> >>>> appreciated. Thanks,
> >>>> Gregg
> > 
> > 
> 
-- 
Steve Chiswell <address@hidden>
Unidata