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

[GEMPAK #SKK-738821]: dcgrib2 problem with GEMPAK5.11.4

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [GEMPAK #SKK-738821]: dcgrib2 problem with GEMPAK5.11.4
  • Date: Tue, 18 Aug 2009 16:20:22 -0600
Hi James,

You're going to want to check that ENSEXT is not set to 1 in your pqact.gempak 
entries for ensemble grids.  

From the dcgrib2 man page,

http://www.unidata.ucar.edu/cgi-bin/gempak/manual/decoders_index?dcgrib2

ENSEXT : Environmental variable for adding ensemble extensions to parameter 
names
                If ENSEXT is not set, use of PDSEXT parameter name extensions 
defaults 
                to yes for grib1 and no for grib2. If ENSEXT is set, and equal 
to 1, 
                then the extension will be added to parameter names. If ENSEXT 
is
                set, and not equal to 1, the PDS extension will not be added to 
parameter 
                names.


That should do it, let me know if you have further questions.

Michael James
Unidata User Support



> Hi,
> 
> I installed the latest GEMPAK(5.11.4) last week, and I noticed some
> problems. For this email, I'm addressing a problem with how dcgrib2
> decodes GFS ensemble and RUC data(via the CONDUIT feed). What I see is
> dcgrib2 labeling ensemble parameters with the run variation name.
> That is, if one looks at temperature data, dcgrib2 produces labels of
> TMPKP001, TMPKP002, ...TMPKP20(TMPKC002 for the control run) for any
> given level. The prior version(5.11.1) just used the label, TMPK
> regardless of ensemble member(this is the preferred labeling). Also, for
> RUC data, there is no VCORD name given for ones that should be labeled
> "HYBL"(using gdinfo program to view all this). Again, the previous
> version did not omit this.
> 
> Since I didn't see any mention of the above in the support email
> archive, I'm assuming that my GEMPAK didn't compile quite
> right(functional  but with flaws). It was installed on a computer with
> OS Mandriva 2008(a derivative of Redhat, I'm told). I've attached the
> make.out using g77(got a similar result compiling with gfortran). I
> compressed the file as it's rather large(2 megabytes). There were no
> "fatal" errors, but many warnings show up. However, I should tell you
> that for the previous version, a lot of similar warning messages
> occurred too. 5.11.1 continues to be our operational version for
> now(I've not encountered any relevant problems with usage).
> 
> I'd appreciate your input on what I can do to correct some of these
> warning statements(if they are relevant for a correctly functional
> GEMPAK package). It's possible that another problem related to how NMAP2
> works might then be corrected(then, I won't need to send a separate
> email for this problem).
> 
> James
> 
> --
> ----------------------------------------------
> James Murakami
> Staff Meteorologist/Student Affairs
> Department of Atmospheric and Oceanic Sciences
> University of California, Los Angeles
> 405 Hilgard Ave.
> Los Angeles, CA  90095-1565
> 
> 
> e-mail: address@hidden
> telephone: 310-825-2418
> Fax: 310-206-5219
> ----------------------------------------------
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: SKK-738821
Department: Support GEMPAK
Priority: Normal
Status: Open