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.
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