NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Neil, Regarding your question as to GEMTBL, and when I said that all programs know to look under the appropriate subdirectory from $GEMTBL, the answer is yes, all programs know to look under the appropriate subdirectory of $GEMTBL. Now.....to clarify the difference between the directory paths for some of the decoders: 1) in general, if you are running the decoder with the $GEMTBL environmental variable set, then you do not have to specify the path. Most interactive users of Gempak source the Gemenviron file which sets the GEMTBL variable- however, the LDM account is typically not set up to run the LDM pqact with GEMTBL set, so the paths are included in the decoder invocations. 2) For the standard decoders like dchrly and dcuair, there are several options, such as -s and -p which specify the actual station table or packing file. If you were running these decoders with the GEMTBL environmental variable set, you could simple use "-s sfmetar_sa.tbl" or "hrly.pack" for example, and the decoder would know to look under $GEMTBL/stns or $GEMTBL/pack as appropriate. Without GEMTBL set, the propper invocation gives the complete path to the file which you see as /home/gempak.....gempak5.4/tables/stns/sfmetar_sa.tbl and others. 3) The "-g" flag is different, because it does not specify a specific file such as -s and -p do. The -g flag only specifies the path to GEMTBL, and the decoder looks for all required files there. Unlike -s and -p where you may chose to change which station table or packing file to use, dcgrib determines which configuration files are needed and opens them as appropriate. In other words, if you are specifying a file on the invocation line in pqact.conf, you will provide the complete path to the file. In the case where the decoder needs to make a choice as to which tables to open (eg NCEP vs ECMWF grib tables, version 1,2,3 etc), I chose to make the options as short as possible where you only need to give the path to the tables, rather than forcing you to know apriori what model center (ncep, ecmwf, ukm, fsl, etc) and what grib version (1,2,3 etc) would be included in the grib messages. As an example, assume you are receiving the ETA model from NCEP and passing it to dcgrib. Dcgrib starts by reading the grib message and determining that the model center is 7 and the grib edition is 2. Dcgrib then looks in $GEMTBL/grid/cntrgrib1.tbl and sees that center 7 is NCEP. Dcgrib can then tell it needs the tables grdnav.tbl, wmogrib2.tbl and ncepgrib2.tbl. The wmogrib2 tables defines the parameter numbers 1-127, and ncepgrib2 defines those parameters 128-255 which are specific to ncep. So, the -g flag is simply a shortcut to having to name all 4 of those tables on the command line...besides, you would have to know what tables all of the different grids were going to need- and when they changed grib editions etc. If you run dcgrib from the command line and have GEMTBL already set, then you do not have to specify -g at all. In fact, the -g flag exists just to set the GEMTBL environmental variable in the environment of the pqact process which executes the decoder. Does that explain the difference between the usages? Steve Chiswell Unidata User Support >From: "Neil R. Smith" <address@hidden> >Organization: Dept. Meteorology, TAMU >Keywords: 199910272026.OAA04465 >Unidata Support wrote: >> >> Neil, >> the -g flag passes the GEMTBL directory location to dcgrib >> since its not generally set as an environmental variable in the >> LDM users profile. >> >> It should point to $NAWIPS/gempak5.4/tables/ >> All of the gempak programs know to look in grid, stns, colors, luts >> etc under that directory as needed. >> >Steve, >"All of the gempak programs know to look in ..."? Hmm. In your gempak >example pqact.conf, entries for some dc* utilities provide a >full path. eg., > ># GEMPAK Point source decoders ># >NLDN >^([0-9][0-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9]) > PIPE /usr/local/ldm/decoders/dcnldn -m 25000 -s minute05 > -d data/gempak/logs/dcnldn.log -v 1 > -p /home/gempak/NAWIPS-5.4/gempak5.4/tables/pack/nldn.pack > data/gempak/nldn/YYYYMMDDHH_nldn_@@.gem > > ># US and Canadian sfc obs and specials ># >DDS|IDS ^S[AP].* .... ([0-3][0-9])([0-2][0-9]) > PIPE /usr/local/ldm/decoders/dchrly -v 1 -b 9 -m 24 > -d data/gempak/logs/dchrly.log > -p /home/gempak/NAWIPS-5.4/gempak5.4/tables/pack/hrly.pack > -s /home/gempak/NAWIPS-5.4/gempak5.4/tables/stns/sfmetar_sa.tbl > data/gempak/surface/YYYYMMDD_sao.gem > >I fear I'm speaking from utter stupidity, but these represent >specific files in the 'tables' tree. Did you really mean >"All of the gempak"? > > >-Neil >-- >Neil R. Smith address@hidden >Computer Systems Manager 409/845-6272 FAX:409/862-4466 >Dept. Meteorology, Texas A&M Univ. >