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.
Robert, I haven't duplicated your problem with SFC_HRLY yet....but I did find a problem with the TAFS_DEC section where the files from the dctaf action are being named YYYYMMDDHH_taf.gem and the nwx program is always expecting YYYYMMDD(extension) names. So, I thought I'd verify once again that your surface files are name YYYYMMDD_sao.gem (and don't have the hour). This also means that if you are using the dctaf decoder and the suggested file naming, you should have the same problem with those reports. Basically, the first call to the directory returns an error when the file names aren't of the expected format. The second call using the same master.tbl category will skip the directory scanning for the sake of speed since the category is the same- but doesn't know that the directory was empty. Steve Chiswell >From: Robert Mullenax <address@hidden> >Organization: UCAR/Unidata >Keywords: 200305062023.h46KNT7U020274 >> > >Sorry, I should know better than to type something from memory. You are corre > ct. >I have exactly what you have there. Nothing has been modified. > >Robert >> Robert, >> >> I'm trying to follow your steps below, but you don't mention the same >> categories that I have. Lets verify: >> >> 1) Open nwx >> 2) Click on "Observed Data", you said "surface obs" which is not in my dist >> 3) Click on "Surface Hourlies" >> 4) Set time range >> 5) Click on station >> >> The master.tbl entry for SFC_HRLY is: >> SFC_HRLY sfstns.tbl O $GEMDATA/surface _sao.ge > m >> >> That is expecting files named yyyymmdd_sao.gem in $GEMDATA/surface. >> If thats not what you have, then lets see what master.tbl entries you are us > ing. >> >> Steve Chiswell >> Unidata User Support >> >> >> >> >> >From: Unidata Support <address@hidden> >> >Organization: UCAR/Unidata >> >> > >> >Robert, >> > >> >The mangling of the string below with the "dm/gempak/surface" >> >getting tacked on seems to indicate either a string that >> >is not properly null terminated, or is exceeding the length. >> >The fact that certain versions usually work is probably >> >a side affect of optimization in the compiler (less optimization >> >sometimes keeps variables separated in memory space so that not >> >crashing is merely fortuitous). >> > >> >I can look at the code and see if there is a memory problem. >> > >> >Steve Chiswell >> >Unidata User Support >> > >> > >> > >> >>From: Robert Mullenax <address@hidden> >> >>Organization: UCAR/Unidata >> >>Keywords: 200305040336.h443aI7U004383 >> > >> >> >> >>In the past I have had trouble with locally built (Sun compilers SPARC and > x8 >> > 6 >> >> Solaris) >> >>versions of nwx core dumping while trying to read surface obs. I experien > ced >> >>the aame thing on x86 (wxmcidas.nsbf.nasa.gov) with 5.6j, however, this ti > me >> >>my usual fix of getting the Unidata binary for nwx didn't work either. It > al >> > s >> >> o core >> >>dumps. >> >> >> >>I open nwx, select surface obs, click on one station and get station not f > oun >> > d >> >> (even >> >>though it is there and sflist verifies that). If I do nothing else all is > fi >> > n >> >> e.. >> >>if I select another station then I get these errors writen to the terminal > : >> >> >> >>/export/home/gempak% nwx >> >>Resource File: /export/home/gempak/GEMPAK/resource/Nwx >> >> [FL -1] Cannot open file /var/data/ldm/gempak/surface/dm/gempak/surface. >> >> [SF -2] File /var/data/ldm/gempak/surface/dm/gempak/surface could not be > op >> > e >> >> ned. >> >>Segmentation fault (core dumped) >> >> >> >>I have verified that Gemenviron and ~/gempak/nwx/master.tbl are correct, t > hat >> > >> >> the >> >>data path is /var/data/ldm/gempak/surface...so it's somehow mangling >> >>the path. >> >> >> >>I could go back and use an older version of nwx, but we find some of the n > ew >> > f >> >> eatures in >> >>nwx 5.6j to be useful and nice. >> >> >> >>Thanks, >> >>Robert >> >> >> > >> > >> >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8643 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://my.unidata.ucar.edu/content/support >> **************************************************************************** > >