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.
Eric, Your glibc has non-standard defaults for processing the command line arguments. I have a work around. You you want the source or binary? Steve Chiswell >From: Eric Nelson <address@hidden> >Organization: UCAR/Unidata >Keywords: 200308300106.h7U16mLd015885 > >Steve, > >I broke up the regular expresssion as suggested. ldmpqactcheck was happy >again. I HUP'd pqact and....still not working right. > >I went back to the previous email with instructions to test the decoder >outside of ldm. Used pqcat to make a file with all the pieces as >suggested. This yeilded a 676k test.klot file. No error noted onscreen. > >I tried to run this file thru the decoder using... >cat test.klot | dcnexr2 -s KLOT -v 4 -d - test.out > >This produced 2 files. One file was named "4" and was 9.3M and the second >file was KLOT and was 269 bytes. "4" appeared to be the data while KLOT >ended up looking like a log file. Contents of KLOT appear below... > >[23938] 030829/2000 [DC 3] Starting up. Version 5.6.k >[23938] 030829/2000 [DCNEXR2 -1] new output file .4 >[23938] 030829/2000 [DC 5] Normal termination. >[23938] 030829/2000 [DC 2] Number of bulletins read and processed: 44 >[23938] 030829/2000 [DC 6] Shutting down. > >It looks as if the decoder is the problem after all. > >-Eric > > > >On Fri, 29 Aug 2003, Unidata Support wrote: > >> >> Eric, >> >> OK....now we may be looking at a pqact parsing problem with pqact.conf. >> To shorten the regular expression, I'd suggest: >> CRAFT BZIP2/(....)/(........)(....) >> PIPE decoders/dcnexr2 -s \1 >> -d data/gempak/logs/dcnexr2.log >> data/gempak/craft/\1/\1_\2_\3 >> >> The regular expression above is sortened, and you can use multiple >> lines for the action (using TABS for the continuation lines of course). >> Just for the sake of clarity, the above is: >> CRAFT <TAB> BZIP2/(....)/(........)(....) >> <TAB> PIPE <TAB> decoders/dcnexr2 -s \1 >> <TAB> <TAB> -d data/gempak/logs/dcnexr2.log >> <TAB> <TAB> data/gempak/craft/\1/\1_\2_\3 >> >> >> Steve Chiswell >> >> >> >> >> >From: Eric Nelson <address@hidden> >> >Organization: UCAR/Unidata >> >Keywords: 200308290239.h7T2dnLd006481 >> >> > >> >Steve, >> > >> >Reread pqact (pqactHUP) and the files are still being written into the >> >places I mentioned before. I then tried specifying an explicit path of >> >/home/ldm/data/gempak/craft/ with no luck. It seems taht I could place >> >just about anything in the pqact entry and it would make no >> >difference. .KLOT still writes to /home/ldm/ and KLOT is created as a >> >file and not a directory. >> > >> >Something else I noticed, I've copied and pasted the default entry >> >different places with in my pqact file so I can test different paths after >> >"PIPE". Each time I copy&paste, ldmadmin >> >pqactcheck flags the pattern line for being too long, even though it is an >> >exact copy of what I have a few lines above (which does not get flagged.) >> > >> >FYI we are running ldm 6.0.13 and debian linux 3.0 >> > >> >-Eric >> > >> >On Thu, 28 Aug 2003, Unidata Support wrote: >> > >> >> >> >> Eric, >> >> >> >> The GEMPAK decoders will write to the ~ldm/logs/ directory if >> >> the -d path/name option isn't specified. >> >> >> >> Presumably you have run "ldmadmin pqactHUP" or restarted the >> >> LDM after making any edits to pqact.conf....since until >> >> then, no changes you make will take effect. >> >> >> >> Certainly go ahead and delete those files and make sure your pqact >> >> has reread the entries. See if the files are recreated. >> >> >> >> Steve Chiswell >> >> >> >> >> >> >> >> >> >> >From: Eric Nelson <address@hidden> >> >> >Organization: UCAR/Unidata >> >> >Keywords: 200308282113.h7SLDnLd025401 >> >> >> >> > >> >> > >> >> >I found that dcnxer2.log is really being written in /home/ldm/logs/ and >> >> >that a single file (not dir) named KLOT existed in /home/ldm/ >> >> > >> >> >The log file is absent any errors. Standard start/stop stuff. >> >> > >> >> >[26238] 030828/1504 [DC 3] Starting up. Version 5.6.k >> >> >[26238] 030828/1520 [DC 5] Normal termination. >> >> >[26238] 030828/1520 [DC 2] Number of bulletins read and processed: 28 >> >> >[26238] 030828/1520 [DC 6] Shutting down. >> >> > >> >> >My pqact entry is still... >> >> > >> >> >PIPE decoders/dcnexr2 -s \1 -d data/gempak/logs/dcnexr2.log data/gem >> > pak/craf >> >> > t/\1/\1_\2_\3 >> >> > >> >> >so I'm puzzeled as to why it wants to write elsewhere. >> > > >> >> >-Eric >> >> > >> >> >On Thu, 28 Aug 2003, Unidata Support wrote: >> >> > >> >> >> >> >> >> Eric, >> >> >> >> >> >> I'd suggest storing off a copy of data from the LDM to disk and runnin > g t >> > he >> >> >> decoder by hand to see if that provides a better handle. >> >> >> >> >> >> You could do this like (use whatever pattern to get all pieces of a si > ngl >> > e >> >> >> time: >> >> >> pqcat -o 3600 -f CRAFT -p "20030828194338" -vl- > test.klot >> >> >> >> >> >> Then pass the test.klot file to the decoder with: >> >> >> >> >> >> cat test.klot | dcnexr2 -s KLOT -v 4 -d - test.out >> >> >> >> >> >> It seems that if you aren't seeing a bunch of these decoders piling up >> >> >> in you process list, and the ldmd.log isn't giving you any error broke > n >> >> >> pipe messages, then its possible that the data is being written >> >> >> somewhere unexpected on your system. >> >> >> >> >> >> Steve Chiswell >> >> >> >> >> >> >> >> >> >From: Eric Nelson <address@hidden> >> >> >> >Organization: UCAR/Unidata >> >> >> >Keywords: 200308281929.h7SJTtLd013978 >> >> >> >> >> >> > >> >> >> >Steve, >> >> >> > >> >> >> >climate:/home/data/gempak/craft> ls -la >> >> >> >total 8 >> >> >> >drwxrwxrwx 2 ldm ldm 4096 Aug 27 23:10 . >> >> >> >drwxrwxrwx 18 ldm ldm 4096 Aug 26 20:54 .. >> >> >> > >> >> >> >It has never created the KLOT dir (KLOT is the only site I'm requesti > ng >> >> >> >for now.) I'd show you the log file its creating except it isn't cre > ati >> > ng >> >> >> >one. >> >> >> > >> >> >> >right now I see a process... >> >> >> > 2471 ? R 2:37 decoders/dcnexr2 -s KLOT -d >> >> >> >data/gempak/logs/dcnexr2.log data/gempak/craft/KLOT/KLOT_20030828_190 > 4 >> >> >> > >> >> >> >but data/gempak/craft/ remains completely empty. >> >> > > >> >> >> >-Eric >> >> >> > >> >> >> > >> >> >> > >> >> >> >On Thu, 28 Aug 2003, Unidata Support wrote: >> >> >> > >> >> >> >> >> >> >> >> Eric, >> >> >> >> >> >> >> >> If you have an instance of dcnexr2 running, it will create the dire > cto >> > ry >> >> >> >> (KLOT presumably). Has this been done? The data file will initially > >> >> >> >> be opened in the directory with a "." preceeding the filename speci > fie >> > d >> >> >> >> in order to help with the fact that the data are sent 100 radials a > t a >> > ti >> >> > me. >> >> >> >> The file will be renamed from .filename to filename the first time > the >> > de >> >> > cod >> >> >> > er >> >> >> >> exits. >> >> >> >> >> >> >> >> Steve Chiswell >> >> >> >> >> >> >> >> >> >> >> >> >From: Eric Nelson <address@hidden> >> >> >> >> >Organization: UCAR/Unidata >> >> >> >> >Keywords: 200308281400.h7SE0vLd017431 >> >> >> >> >> >> >> >> > >> >> >> >> >Ok, >> >> >> >> > >> >> >> >> >I've recovered from my earlier typos in pqact so that everything i > s >> >> >> >> >working that was working with version J. I copied all the dc* int > o >> >> >> >> >/home/ldm/decoders where they should be. I'm not seeing anymore w > rit >> > e >> >> >> >> >errors in my ldmd.log file. >> >> >> >> > >> >> >> >> >dcnexr2 is still not creating any output. I used the sample entry > an >> > d >> >> >> >> >modified it to generate a log file in the same place the rest of m > y l >> > og >> >> >> >> >files are. I also changed the data output location for my data tr > ee. >> > T >> >> > he >> >> >> >> >pattern is the same. >> >> >> >> > >> >> >> >> >CRAFT >> >> >> >> >^L2-BZIP2/(....)/([0-9][0-9][0-9][0-9][0-1][0-9][0-3][0-9])([0-2][ > 0-9 >> > ][0 >> >> > -5] >> >> >> > [0- >> >> >> >> > 9])([0-9][0-9]) >> >> >> >> > PIPE decoders/dcnexr2 -s \1 -d data/gempak/logs/dcnexr2.log >> >> >> >> >data/gempak/craft/\1/\1_\2_\3 >> >> >> >> > >> >> >> >> >No log files, No data. When I look at the list of processes runni > ng >> > I s >> >> > ee >> >> >> >> >an instance of dcnexr2 running. >> >> >> >> > >> >> >> >> >The dir that it should be writing to has 777 permissions on it. >> >> >> >> > >> >> >> > >> >> >> >> >> >> ********************************************************************** > *** >> > *** >> >> >> Unidata User Support UCAR Unidata P > rog >> > ram >> >> >> (303)497-8643 P.O. Bo > x 3 >> > 000 >> >> >> address@hidden Boulder, CO > 80 >> > 307 >> >> >> ---------------------------------------------------------------------- > --- >> > --- >> >> >> Unidata WWW Service http://my.unidata.ucar.edu/content/su > ppo >> > rt >> >> >> ********************************************************************** > *** >> > *** >> >> >> >> > > >> >> > >> >> >> >> ************************************************************************* > *** >> >> Unidata User Support UCAR Unidata Prog > ram >> >> (303)497-8643 P.O. Box 3 > 000 >> >> address@hidden Boulder, CO 80 > 307 >> >> ------------------------------------------------------------------------- > --- >> >> Unidata WWW Service http://my.unidata.ucar.edu/content/suppo > rt >> >> ************************************************************************* > *** >> >> >> > >> >> **************************************************************************** >> 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 >> **************************************************************************** >> >