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

19991207: mmos data problem

Art,

If you have your raw data file which has all the observations in it,
then you might try manually running dcmmos on that file
to see if it repeats the problem you are seeing with your realtime data:
cat 1999120700.mrfmos | dcmmos -v 4 -d - YYMMDDHH_mmos.gem

I ran todays raw file here and have 122 bulletins. I do have some alaskan
stations that aren't in the station table. Plotting sfparm=tmpf
I seem to have good coverage in sfmap.

So I guess if you are missing stations in your decoded file that are
in the raw file, it would help me if you could identify those stations 
for me so that I can see if anything has changed in the bulletin structure.

I did patch $GEMPAKHOME/source/bridge/dc/dcgbul.c back in January 22, 1999
(included in the patch 12 distribution) which fixed a problem the gempak
decoders had with some badly formed bulletins- so that would be a timestamp
to check in your gempak distribution.

Steve Chiswell
Unidata User SUpport

On Tue, 7 Dec 1999, Arthur A. Person wrote:

> 
> On Tue, 7 Dec 1999, Steve Chiswell wrote:
> 
> > This sounds like a previous problem with LDM 5.0.5 and earlier
> > that was fixed long ago- but just in case, please check your
> > LDM version.
> 
> I'm running LDM 5.0.8 which was installed September 9, 1999.  I took a
> stroll through the dcmmos log file and it seemed to consistently record
> "Number of bulletins read and processed: 114" until November 16, 1999 and
> then has been very inconsistent in that number (usually less).  The last
> two days, 12/05 and 12/06 seem to have been the best in awhile.  The only
> other thing I noticed was that the time code in the log changed from a
> normal ~11-12Z (e.g. 991109/1157) to ~8-9Z (e.g. 991111/0843).  This
> seemed to occur on November 11, 1999.
> 
> > The previous problem was that for PIPE commands that handled small amounts
> > of data (not surface, upperair etc), basically the PIPE would time out
> > between messages and close the decoder down- but the LDM would not know
> > that the PIPE was closed until the next time a write had to take place-
> > at which point it would fail and start up a new pipe- but having already
> > lost the bulletin that was trying to be written. Again, this is generally
> > noticed in the decoders where data is sparse so that the PIPEs would
> > be scoured by the LDM for other decoders. 
> >
> > Since your FILE action is apparently catching all the data, we should
> > verify that the above is not the case.
> 
> Any recommendations on how I can test this?
> 
>                                          Thanks.
> 
>                                            Art.
> Arthur A. Person
> Research Assistant, System Administrator
> Penn State Department of Meteorology
> email:  address@hidden, phone:  814-863-1563
> 
>