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

20030818: "Interrupt" in dcgrib2 log



Art,

The SIGINT signal is being caught in $GEMPAK/source/bridge/dc/dcsgnl.c
which causes the exit.

I have found 1 possible cause, being a bulletin that did not have the 
trailing 7777 (signalling the end of the grib) and therefore the decoder
kept cycling through the input buffer.....when I believe it should
stop at the specified length of the data stated in the PDS block
of the decoder.

I have added some debugging to try to catch an example of the
grib product that is missing the correct 7777, since asside from
handling the erroneous condition in dcgrib2, NCEP/NWS should
fix the problem if it exists.

Do you know the product that you missed?

Steve Chiswell

>From: "Arthur A. Person" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200308181924.h7IJOQLd021914

>Hi...
>
>I was wondering if you know what "Interrupt" in a dcgrib2 log might mean.
>I got one *approximately* around the time that I lost a grid field that
>should have been decoded in a gempak output file for the ETA model.  The
>lines nearby in the log are:
>
>[23085] 030818/1244 [DM 0]
>[23085] 030818/1249 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1249 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1249 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1249 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1249 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1250 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1250 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1250 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[23085] 030818/1250 [DCGRIB -50] griblen [1234594] > maxgribsize [1000000]
>[23085] 030818/1319 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1320 [DC 3]
>[13628] 030818/1320 [DC -11]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1329 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1330 [DCGRIB -50] griblen [1234594] > maxgribsize [1000000]
>[13628] 030818/1354 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1354 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1359 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1359 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1359 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1359 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1359 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1359 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1402 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1408 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[13628] 030818/1414 [DC 2] Interrupt Signal
>[13628] 030818/1414 [DC 5]
>[13628] 030818/1414 [DC 2] Number of bulletins read and processed: 9330
>[13628] 030818/1414 [DC 6]
>[19966] 030818/1415 [DC 3]
>[19966] 030818/1415 [DC -11]
>[19966] 030818/1422 [DCGRIB -55] Grid too large 1830 x 918 [1679940 >
>400000]
>[19966] 030818/1427 [DM 0]
>
>
>I'm running LDM V6.0.14 on RH9 with a dcgrib2 built on RH 7.2 (gempak
>V5.6.h) for this.  The decoded data is being filed over NFS.  The decoder
>seems to have run great except for this one field that was lost which has
>made me a little nervous, so I'm trying to track it down.  I'm comparing
>output from this system with parallel ingest/decoding on another system
>here locally to establish correctness.
>
>                               Thanks.
>
>                                 Art.
>
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  address@hidden, phone:  814-863-1563
>