1999122: 1999122: gpwarn...

Maureen,

The white boxes in Indiana with the purple outlines signify warnings that
have expiration times in the future past the number of
minutes you selected in WWATT. I checked, and Indiana has some
small stream flood warnings with expiration times on the 25th.
I had WWATT=120/1440 so that warnings over 2 hours old wern't plotted
and more that 24 hours in the future were just outlined and white.
I guess you could go to 3 days, 4320 minutes to that you would catch more
of these in the standard color scheme. The original reason I decided
to have an in the future cut off is that some winter storm warnings 
were getting posted several days in advance. I used the white 
with purple to denote an impending condition- though may or
maynot be occuring at that moment.

I didn't see any brown areas in MS....I looked at your gif's of
16:36 and 17:06EST. I'll check back on occasion.

Steve


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

>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.
>>
>
>I am still picking up a few messages (right now they are in MS) which gempak i
> s plotting
>as brown (so that would mean it can't tell what the warning is - right?) You c
> an see this
>on our web site at:
>
> http://wwwagwx.ca.uky.edu/unidata/ldm/images/warn_ky.gif
>
>The stuff in IN looks pretty funky too - I have altered our script so that no 
> expired
>warnings/watches should be posted.
>
>> 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
>>
>
>Thanks! Let's see if that will do it!
>
>> 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 hammer
> ed.
>> Otherwise, maybe duplicate bulletins are being found and really slowing thin
> gs 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 wo
> uld help.
>>
>
>When I run it manually and see what is output, it does take a while for it to 
> go through
>all the messages. I did a reboot after receiving a cannot allocate colors erro
> r earlier
>and that has helped a lot. I think that it started to slow down and then I ran
>  it
>manually while it was still running and in the long run everything got backed 
> up.
>Hopefully it will be okay over the weekend.
>
>Thanks!
>
>Maureen
>
>