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.
Stonie, GPWARN is capable of using file aliases. I have the following defined in the $GEMTBL/config/datatype.tbl file: ! Text files for warnings TORNADOWARN $TEXT_WARN/torn_warn YYYYMMDDHH.torn CAT_NIL etc. TSTORMWARN $TEXT_WARN/tstrm_warn YYYYMMDDHH.tstrm CAT_NIL etc. FLOODWARN $TEXT_DATA/fflood/warn YYYYMMDDHH.warn CAT_NIL etc. WINTERWARN $TEXT_WARN/winter YYYYMMDDHH.winter CAT_NIL etc. NONPCPWARN $TEXT_WARN/noprcp YYYYMMDDHH.noprcp CAT_NIL etc. For my script which I use to plot the warnings, I have WWFIL = nonpcpwarn;winterwarn;floodwarn;tstormwarn;tornadowarn (you can define your own aliases...they aren't hardcoded into the program) The program will go back through the files matching the aliases (all files since things like Winter Storm Warnings get issued 24 to 72 hours in advance). The colors and line types are currently hard coded into the routine, but I will take it as a suggestion to make a $GEMTBL/unidata/gpwarn.tbl configuration file. Steve Chiswell Unidata User Support On Wed, 11 Sep 2002, Stonie R. Cooper wrote: > Steve, > > You nailed it! > > Is there a way to get gpwarn to search through the $TEXT_DATA/nwx/watch_warn > tree for all current data, or will it always have to have the files cat'ed to > a large file (as mentioned in the phelp for gpwarn)? > > Also, is the color table compiled in, or a config file (for the fill and > outline colors)? > > Thanks! > > Stonie > > On Wednesday 11 September 2002 18:25, Steve Chiswell wrote: > > Stonie, > > The problem you are having with gpwarn is apparently you had > > set WWS=all. In reality WWS is either "current" or a gempak > > format dattim. The segment fault was from trying to convert > > the "all" string to a number. > > > > I'll try to make that more robust within the expected values. > > > > Steve > -- > Stonie R. Cooper > Planetary Data, Incorporated > ph. (402) 782-6611 >