220 likes | 418 Views
SHARP. S upplemental H ydro- A nalysis & R esponse P rogram. Mark Love / Hydrologist / SERFC. July2007. Background / Motivation. IDP GOALS : Professional / Personal goals to increase proficiency in... GIS OOP Classes Inheritance Sub/Super classes Interface programming Polymorphism
E N D
SHARP Supplemental Hydro- Analysis & Response Program Mark Love / Hydrologist / SERFC July2007
Background / Motivation IDP GOALS: Professional / Personal goals to increase proficiency in... GIS OOP Classes Inheritance Sub/Super classes Interface programming Polymorphism Design Data flow control AWIPS->PC->AWIPS Program control Database control 15,000+ lines of code Integrate previously organized GIS datasets OFFICE GOALS: A couple years ago, John Feldt initiated an overall office goal called FARBII. (FAst Response Basin Improvement Initiative) Policy Tools (i.e. software) SAS SHARP is one software tool (of many) that helps to keep forecasters at a high level of situational awareness. ...With the goal to keep from getting "burned" by those fast responding basins.
SHARP stands for… • S – Supplemental (to official systems) • H – Hydro • A – Analysis – lots of number crunching • R – Looks for River Response • P – Program
Program Goals The goal is to produce a "RiverWatch"-type program that will look for hydro problems and will produce alerts / products based on what it finds. Create an alert for Segments that... are currently flooding are forecast to flood are forecasts that need updating are rising rapidly, but still below floodstage
Additional Goals • Must… • Have an easy to use GUI • Have a graphical display suitable for SAS • Real-time (up to 20min behind AWIPS) 24x7 operation • Automatic generation of hydrographs / products • for segments that satisfy “alert” criteria • "On Demand" Hydrograph generation from GUI • Products sent back to AWIPS • Afterthoughts: • DSAP (Daily Situational Awareness Product) • Precipitation Visualization (simple) – over fast responding basins • Web graphics (not quite there – orig meant for internal) • “Additional use” of picking up bad data
Sample "Alert" Hydrograph "MIKEOBJECTS" Timeseries Package (free objects to embed)
COMPONENTS SHARP GUI Forecaster interaction, quick hydrograph generation, overview of flood status, overview of flood potential SHARP SEARCHES Programming – interaction with databases to identify “hotspots” GIS VISUALS Flood maps, data exploration, precip overlays, alert maps SHARP 3 STATIC GIS DATABASE 1.) Basins, rivers, dams, lakes, elevation grids, etc 2.) xmrg REAL-TIME DATABASES (2) 1.) Flood status, warning levels, alerts 2.) Data for the last 5 days, future 7 days DATABASE 2 DATA SOURCES The data must be transferred from AWIPS to the Windows PC box. DATA FLOW Data flow (volume) is not always constant. The programming must be flexible enough to have temporary storage. DATA CONVERSION Text files from AWIPS must be formatted for insertion into GIS Databases AWIPS DATA 1
RAW data Batchpst Input Files STG, TWEL, PELV PP01/03/06/24 RQME, QIN, SNOG (ftp’d every 10 minutes) Xmrg grids (ftp’d every 60 minutes) RVF products (ftp’d often) SAC-SMA Model States (ftp’d once a day) TECHNOLOGY Utilized CYGWIN C program to convert Xmrg to ASCII VB.NET program converts an RVF product into simple columns for subsequent insertion to DBs VB.NET performs all searches and number crunching DATA
FAST RESPONSE GOAL: Identify and alert segments that are rising quickly. DIFFICULTY #1: A half foot at location “A” means something different than a half foot at say location “B” DIFFICULTY #2: It’s too messy dealing with individual observations to come up with a rate. DIFFICULTY #3: “Weed out” normal regulation activity / tidal effects. DIFFICULTY #4: “Weed out” data that is far below flood stage.
STATISTICAL CALCULATIONS (to identify fast river rises) 1.) Mean(24-0) > Mean(48-24) 2.) Variability(24-0) > Variability(48-24) 3.) MAXob(24-0) > (LowestAlertSTG – Mean(48-24) * 0.625) + Mean(48-24)) 48-24 24-0 IF #1 and #2 and # 3, THEN… FAST RESPONSE ALERT False Alarms? Rare, because… • Regulation fluctuations fail #1 and/or #2 • Quick falls fail #1 • “Noise” is filtered by #3
TREND CHECK GOAL: to identify forecasts that may need to be updated • Program retrieves any data available that is less than 3 hours old • Retrieves the value of the oldest ob • Retrieves the value of the most recent ob • Calculates Rising/Falling/Steady • Determines if we can reach our next forecast time by this trend • If not, TREND ALERT