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

20010807: dcmetr: not processing locally-ingested METAR?



Christian,

I downloaded 2 bulletins from your LDM and decoded them with dcmetr:
ldm% feedme -v -l - -h io.sca.uqam.ca -p "SAFR33" -o 3600 > test.data
:      157 20010807163331.120     IDS 000  SAFR33 LFPW 071600
:       96 20010807170334.610     IDS 000  SAFR33 LFPW 071630

They did decode OK with dcmetr, so we know that works as your message states.
I also was successful in using the pqact.conf entry you have (with paths
appropriately changed)

You are correct that you don't want more than 1 decoder writing to a file.

Your action below doesn't specify a "-s" option, so you will use the sfstns.tbl
station table, which doesn't have those stations in it. If your surface file
was already created before you added those station locations to the table,
then your GEMPAK file won't have them either.

By default, room for 200 additional stations is allotted unless you
specify more room with "-a". So, if your GEMPAK file was created by dcmetr 
before 
you added the stations to sfstns.tbl, you won't see the stations unless they
are one of the first 200 "new" stations received that aren't in the table.

If you have added the sfstns.tbl entries, you should start seeing 
the stations in the GEMPAK files when a new output file is created
tomorrow.

If you still don't see the stations, then try adding the "-v 4" option
to dcmetr to see where the decoder is upset with the bulletin.

Steve Chiswell
Unidata User Support





>From: Christian Page <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200108071012.f77ACJ118901

>
>Hi,
>
>I still have some problems regarding dcmetr and locally-ingested METAR. Here's
>  a
>wrap-up again of my problem:
>
>--------------------------------------
>
>I generate, from 2 metar reports, by example:
>---cut here---
>^A^M^M
>981 ^M^M
>SAFR33 LFPW 070900^M^M
>METAR^M^M
>LFJL 070900Z AUTO 26010KT 9999 SCT058 SCT070 30/15 Q1022=^M^M
>LFBG 070900Z 36006KT 320V040 CAVOK 31/16 Q1024=^M^M
>^M^M
>^C
>--- cut here ---
>
>I create this text file where ^C etc. are control characters. The EOF of the
>file is just after the ^C. There is no ^J there. The 981 is a dummy number.
>SAFR33 is a new dummy WMO header that doesn't exist in the IDS feed.
>
>This report is processed correctly by pqact and pqsurf: I get the in my gdbm
>database (pqsurf) and in my raw WMO text files (pqact). The problem is that th
> ey
>are not put into my gempak files using this pqact.conf entry:
>
># International sfc obs and specials in hourly files yymmddhh_sao.gem
>WMO     ^S[AP].... .... ([0-3][0-9])([0-2][0-9])
>        PIPE    /io/gempak/nawips/bin/irix/dcmetr -b 9 -m 72
>        -d logs/dcmetr.log
>        -e GEMTBL=/io/gempak/nawips/gempak/tables
>        data/gempak/surface/sao/YYYYMMDD_sao.gem
>
>This works for all reports except those I ingest locally.
>
>------------------------------------------
>More, if I run dcmetr manually, as:
>
>cat "SAFR33 LFPW 070900" | /io/gempak/nawips/bin/irix/dcmetr -b 9 -m 72 -d  \
>logs/dcmetr.log -e GEMTBL=/io/gempak/nawips/gempak/tables test.gem
>
>it works. If I run sflist and list the data, these stations are there. Also if
>  I
>edit the binay gempak file in emacs, I can find LFBG in there.
>
>-------------------------------------------
>But if I try to put it manually into my realtime gempak file, it doesn't work
>neither:
>
>cat "SAFR33 LFPW 070900" | /io/gempak/nawips/bin/irix/dcmetr -b 9 -m 72 -d  \
>logs/dcmetr.log -e GEMTBL=/io/gempak/nawips/gempak/tables \
>/io/ldm/data/gempak/surface/sao/20010807_sao.gem
>
>but in that case, maybe I have the risk to corrupt my file since a dcmetr
>invocation is writing at the sametime in the file. Running sflist yields to no
>data from LFBG, and editing read-only the file into emacs, I cannot find any
>LFBG string neither.
>
>--------------------------------------------
>
>Also, as a note, I assured that LFBG was in the station list tables files, and
>  I
>added an LFBG entry when missing. But this didn't help.
>
>Any hint?
>
>Christian Page
>UQAM
>