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.
David, You might look back in the logs and see if there are indications that more than one instance of dcmetr is running at a time (eg overlapping process IDs in the log messages). Pqact could have problems with a pipe and end up starting up a new stream if the PIPE had trouble. Other than that, I'd start suspecting something like storing the raw text bulletin ran into a bug....but if that doesn't occur when running manually, it would seem less likely. Steve Chiswell Unidata User SUpport >From: David Wojtowicz <address@hidden> >Organization: UCAR/Unidata >Keywords: 200204261606.g3QG6fa19127 >Hi, > > Periodically I discover that I have a corrupt GEMPAK surface file from DCMET > R. >In the $SAO directory, I'll find something like this: > >-rw-r--r-- 1 423 48 14386180 Apr 22 18:13 020419_sao.gem >-rw-r--r-- 1 423 48 14341124 Apr 22 18:14 020420_sao.gem >-rw-r--r-- 1 423 48 13810180 Apr 22 18:14 020421_sao.gem >-rw-r--r-- 1 423 48 14444036 Apr 23 23:47 020422_sao.gem >-rw-r--r-- 1 423 48 14244864 Apr 24 23:00 020423_sao.gem >-rw-r--r-- 1 423 48 14240256 Apr 25 21:20 020424_sao.gem >-rw-r--r-- 1 423 48 14757376 Apr 26 15:37 020425_sao.gem >-rw-r--r-- 1 423 48 312929792 Apr 26 15:37 020426_sao.gem > >The last file here is way too big and corrupt such that GEMPAK >programs can't read it. In the log file produced by DCMETR, I find >the lots of the following > >[6298] 020422/1136 [FL -4] Cannot read file .... >[6298] 020422/1136 [FL -4] Cannot read file .... >[6298] 020422/1136 [FL -4] Cannot read file .... >[6298] 020422/1136 [FL -4] Cannot read file .... >[6298] 020422/1136 [FL -4] Cannot read file .... >[6298] 020422/1136 [FL -4] Cannot read file .... > >or slightly different: > >[28963] 020425/2308 [FL -4] >[28963] 020425/2308 [FL -4] >[28963] 020425/2308 [FL -4] >[28963] 020425/2308 [FL -4] >[28963] 020425/2308 [FL -4] > >They are usually all the same time and then come to an abrupt stop, >after which there are no more entries until I terminate ldm and >restart it. > >My pqact entry looks like this: > >DDS|DDPLUS|IDS ^S[AP].* .... ([0-3][0-9]) > PIPE /home/cirrus/a/gempak/NAWIPS-5.6E/bin/linux/dcmetr > -v 1 -b 9 -m 24 > -d /home/cirrus/a/gemdata/logs/dcmetr.log > -p /home/cirrus/a/gempak/NAWIPS-5.6E/gempak/tables/pack/metar.pack > -s /home/cirrus/a/gempak/NAWIPS-5.6E/gempak/tables/stns/sfmetar_sa.tbl > /home/cirrus/a/gemdata/surface/YYMMDD_sao.gem > >I'm running NAWIPS-5.6E on Redhat Linux 6.2 on this particular >machine that is dedicated only to gempak decoding and fileserving. >This problem has occurred on 3-4 days in the last two weeks. > >Restarting doesn't help if it is the same day still unless I delete >the corrupt file. > >Running a collection of archived DDPLUS products for the day back >through dcmetr , it manually produces a correct file, which I can >copy into place into $SAO and restart from there. > >Thanks for any advice you can offer. > > > > >-- >| David Wojtowicz, Sr. Research Programmer >| Department of Atmospheric Sciences Computer Services >| University of Illinois at Urbana-Champaign >| email: address@hidden phone: (217)333-8390 >