[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unidata 64-bit N-AWIPS binary question
- Subject: Re: Unidata 64-bit N-AWIPS binary question
- Date: Mon, 09 Apr 2007 12:31:52 -0600
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