[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20020426: DCMETR problems

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.

  • Subject: 20020426: DCMETR problems
  • Date: Fri, 26 Apr 2002 11:18:55 -0600
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
>