Water Resources Discipline ITAC Activities

_____________________________________________

Scott,

First a few general comments for your consideration and then a few comments on the attached document.

General Comments

If you track the data from the field to the web “gage to page”, perhaps the inclusion of some figure showing this would help the reader understand the system. There are a number of weak points that could be addressed. Below is an example that could be modified to include more detail on the link between the satellite and the web, including network hardware. Just a thought.

DCP and other real-time data collected at the site is certainly the responsibility of the Science Center. Once in the satellite stream, there are several week points, one being no backup for Wallops Island – but this may beyond the scope of our charge.

If a Science Center LRGS goes down or power goes out to a Science Center server then NWIS-RT should kick in. Should this happen automatically? Generally someone in the District monitors this over the weekend and certainly during extreme events, but the use of Big Brother tools may help. However, some outages may result from intentional downtimes to install/update software. During these times we may not want an automatic failover. Some additional checking, like a flag set for auto failover, before Big Brother automatically takes over might be needed. Furthermore, there are a number of Science Centers, NC included, which collect and process a great deal of real-time data from non-GOES systems and NWIS-RT has a depot set up to accept this data. If we automate the initiation of NWIS-RT will this include an automated transfer of non-GOES data?

Also, as in the Alabama example and in other cases, we need a human contact rather than just an email address when there are problems with the network or NWIS-RT or NWIS Servers that are causing a lapse in the delivery of real-time data.

Regarding WRD network issues, this is where my expertise leaves off and I have come to rely on Nelson and others to ensure that we remain connected to the network and transferring data. But once again, we need a human contact rather than just an email address or an answering machine that may result in hours or days passing before being read or heard and I believe that you have addressed this in the attached document.

A few comments on the document.
Regarding Tools and Processes Available.
1 -- I am not familiar with the “Real-Time Data Delivery System Report.” Is this report available on the web somewhere. You might consider including the URL, if it is. -- I see that it is listed in your email to Greg below.
2 -- As noted above, regarding the use of Big Brother, I am not sure that automated failover is necessarily the way we want to go, without some additional checking first.
3 – I like the idea of someone being assigned to monitor the status of the network at least 18x7.

Regarding Tools and Processes that are Missing.
1 – Only allow failover if some other condition is met too – like a flag that is set for auto failover. For example, if we are actively installing software and will be up in 3.5 hours we may not want to invoke NWIS-RT. Or if a District has a generator set up and is actively processing data on their own NWIS server and doesn’t want to invoke NWIS-RT because there is no two-way update to the District NWIS database from NWIS-RT, then auto failover may not be warranted.
2 and 3 – Yes we need to be able to contact someone!
4 and 5 – Yes! Here in NC we have top notch staff that make sure all processes are up and running after any server problems, but troubleshooting steps and a checklist would certainly help.

Thanks for taking the lead on this. If you have any questions regarding my comments or need additional input feel free to contact me. I am very interested in the progress of this issue.

Jeanne Robbins
Surface-Water Specialist, Data Chief
USGS -- Raleigh, NC
(919) 571-4017
http://nc.water.usgs.gov/

Hi Jeanne,

Bill Carswell referred me to you as a person (Data Chief) very interested in improving tech support availability around the clock and on weekends for the network and other links in the chain between "gage and page" ... i.e. our ability to acquire and deliver real-time streamflow information on the Web. So, I'm following up on his charge to define our requirements.

I've not been "firing on all cylinders" lately, and need your help with this very rough draft, attached below. At the moment, it's a cut and paste of Bill's notes along with some ideas I've added. I've already recruiting Greg Shank's (IT'er in PA) help and will probably ask Sun_TAC for more ideas. But, your ideas will be unique. So, could you find time to help me iterate to a better position/issue paper this week? I'd like to "wrap it" for an ITAC meeting next week.

--- Support Document for Review

If you can't make time this week, I understand. I'm at fault for procrastinating.

By the way, I sure like and admire the heck out of both Nelson Williams and Bill Hazell! In fact, it just occurred to me to add Nelson to this note! ... an indication of how slowly my brain is functioning these days. I know Nelson can help me too, 'cause he knows what the problems are. Other great people in NC: Jerad (who chaired ITAC ... CPAC at the time), Ramona (who moved our public web site to NatWeb), and Boo (who was the NC rep at our ADAPS Train the Trainer training a few years ago).

Scott McEwen - (303) 445-4617
Central Region Computer Specialist, Denver, CO

Hi Greg,

Hope all is well w/ you and the fam. I'm healthy, but I've pretty much thrown up my hands w/ work. Oh well.

Could you take 5 minutes to read the attached and ... maybe 10 minutes to doctor up my screwups? Thanks much, if you can.

--- Support Document for Review

The Real-Time Data Delivery System Report mentioned under "Scenarios" is the old thing at:
http://wwwrcolka.cr.usgs.gov/uo/rtdds/rtrpt.html

--Scott