To ER333:
I really like your 7 step plan for conducting more through diagnostics of the cause and extent of the dam “green spot” and associated settlement (post 3554). The only way to make sure that “unseen unknowns” don’t bite you in the ass is to make them seen and get to know them.
However, more extensive dam diagnostics are not in this year’s current work plan (that we know of). But putting in some or most of the spillway is in the current work plan.
I’d like to get your thoughts on what types of diagnostic instrumentation should be included in, under, and around the spillways. The contract specs for any such instrumentation are probably just now being drawn up, so it seems such focused speculation could be timely.
My preliminary thoughts:
Any modern embedded sensor should be wedded to a microcontroller to continuously check for threshold changes and to handle communication. Temperature and acceleration are basically builtin to many embedded controllers. Pizos could be added for pressure. Acoustic microphones are simple and cheap. Flow and turbidity sensors could be added to the drain pipes. Embedded strain gauges can be temperamental and break easily, so where possible, strain and settlement might best be measured externally via terrestrial scanning Lidar or perhaps inSAR satellite. The more critical instrumentation should be accessible and replaceable for upgrades, where access should be easier in a spillway than a dam. If someone were to put together such a extendable instrumentation package, now would be the time to prototype and test it.
Better diagnostics can lead to applying an once of prevention, rather than the current pound (or a ton) of cure. What types of diagnostics should be built in to the new spillway?
I would keep sensors as simple and reliable as possible. I would provide accessibility for service, and have redundancy to systems.
Modern microprocessor or microcontroller units, even simplified, rely on expertise you do not know if the engineers are versed in the subtle failure modes (physics, truncated branch code threads, code loop proven certainty, power supply integrity, component ratings margins for extra life & certainty, etc).
I helped on a case where a very rare & unknown glitch in a natural gas customer electronic microprocessor unit caused an $80,000 dollar overcharge. The customer proved to the utility that this was impossible based on their average use and the weather at that time. It turns out that the engineers designed the EEPROM storage of flow rate data to be without ECC (error check and correct). Thus, a single bit degradation of the "tunneling" charge method to a floating gate substrate could experience a "charge" loss resulting in a soft bit error. Either the engineers were completely oblivious to this real effect or they didn't think that the calculated possibility of the datasheet spec rate for this phenomenon would manifest. The other issue is code reliability. Compilers can be so high level that you don't always know what the core executable assembly language instruction blocks/loops are generated. That is why they have revisions - due to the bugs in compilers.
In high reliability systems, even the microcontroller code has to be carefully written, tested, and verified in all combinations of input conditions and timing loops. Not many engineers are versed in this ability today. Even then, microcontroller designers have integrated "watch dog" reset circuits - just in case.
Choose wisely if anyone wants to install modern electronics into a high reliability complex system. There is nothing wrong with a very reliable but old fashioned mechanical system (such as the hydraulic piezometers & tubing).