NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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 > >
