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

1999122: gpwarn...

>From: Maureen Ballard <address@hidden>
>Organization: UK Ag Weather Center
>Keywords: 199901221728.KAA20370

>Steve,
>
>With so many warnings out today, it is taking up to 40 minutes for our
>warning script to run! I figured it had to do with all of the warnings
>that have been issued but then I took a look at your example - it seems
>to only take your program a 1 minute or 2 to run - what's the secret?
>
>Thanks for any advice!
>
>Maureen
>

Maureen,

I'm still trying to figure out your previous message. I looked
at the WUUS1 from KPAH, and that seemed to plot for me, so if
you have any info messages on what was output, they would help.

After checking into your report of missing watches, I found that
some of the WWUS40 bulletins have an extra carriage return "\r"
before the bulletin end sequence \r\r\nETX which is confusing
the gempak routine that gets a complete bulletin, and therefore
the bulletin is never being sent to the decoder. I'll have to
check other bulletins to see if this is particular to NOAAport
or just the WWUS40 bullins.

Here is the quick fix for the watches,

edit the $GEMPAKHOME/src/bridge/dc/dcgbul.c routine, and
at line 302, change the finite_state = CR_ to be finite_state = CR_CR_.

This will look like:
/*
**                  If two Carriage Returns have been found, check for
**                  a Line Feed.
*/
                    case CR_CR_:
                        if  ( ch == CHLF ) {
                            finite_state = CR_CR_NL_;
                        }
                        else
                        {
                            if (  ch == CHCR )          /* EJW - 7/96 */
                            {
                                finite_state = CR_CR_; /* chiz 1/99 */
                            }
                            else
                            {
                                finite_state = IN_BULLETIN;
                            }
                        }
                        break;

After editing that routine:
cd $GEMPAKHOME/src/bridge/dc
make clean
make
make clean

cd $NAWIPS/unidata/ldmbridge/dcwatch
make clean
make all
make install
make clean


To find out why its taking 40 minutes to plot the warnings, 
you might want to see how big the warning file is that gpwarn is
mulling through (assuming that is the slow point). Since the
county/zone data base only has to be looked up for current/valid warnings,
the search through those files might be the culprite if it seems to
be spending too long of time on the active bulletins while zipping through
the expired bulletins. If that is the case, disk i/o might be getting hammered.
Otherwise, maybe duplicate bulletins are being found and really slowing things 
up.
Also, the X server could be really slow to respond if network (and nfs) were 
slow.

Again, any more info as to exactly where the really slow part is occuring would 
help.

Steve Chiswell