Firstly! A reminder that
I am fundraising for City Surf Project as part of a group of friends around San Francisco to surf this upcoming Saturday, June 18th, which is International Surfing Day. Please donate! We have less than a week to meet our $1000 goal!
Your author sweating on a rare sunny San Francisco day with the quiver
Secondly... I don't write about my "work" (in the bill-paying sense) as much here as I could. If I'm grumbling about cleaning up data and trying to pull some signal out of the noise, this post is seeking to articulate some of why.
A large part of my work involves deploying sensors at field sites, which record various things about the landscape system. My dissertation research revolves around coastal hydrodynamics and sediment transported by the water, so some of the things I'm interested in measuring with sensors are:
- depth of water over time (so I can see the tides go up and down, for instance)
- suspended sediment concentration ("SSC")
- various wave properties (e.g. mean wave height, peak wave period—ask me about how these get calculated, it's cool)
- fluid velocity (very rad sensors let you see this in 3D)
All of these are interesting in their own right, and they can also all be tricky to measure accurately. Let's take *water depth* as a place to start: how do you actually measure that?
Most sensors take advantage of the piezometric effect, making use of a known and stable relationship between some measured voltage (as output by the sensor) and the pressure applied to the sensor. Then, if I want to turn this
pressure value into a
water depth value, I need to make some adjustments. First I need to subtract atmospheric pressure at the sensor location—because everything except for the atmospheric pressure is the pressure due to water that submerges the sensor (in an open system!). Atmospheric pressure itself changes, roaming around a
typical spread of dbar values as fronts come and go. This requires a dynamic adjustment. Atmospheric pressure shouldn't change very much very quickly or across very small spatial scales, so I often use hourly values from the nearest NOAA meteorological station.
After that subtraction, what's left is the pressure on the sensor due to the "column" of water on top of it. Using an equation that everyone learns in an introductory mechanics or fluids class, p (pressure) = rho (density) * g (gravity) * h (depth). We can solve for fluid depth given a known pressure (which we measured!), gravity (a known constant), and a density value. So here, density becomes the main question.
Water has a remarkably stable density: it can't compress much. But water can dissolve things, and water with dissolved stuff—i.e., salt water—gets denser. Fresh water is about 1000 kg/m3, whereas sea water is typically 1025ish kg/m3. The other main ingredient in water density is its temperature. Warmer water does expand, ever so slightly, whereas colder water shrinks and gets denser. (This is one reason warming oceans are related to sea level rise.) What's best, then, is to measure the temperature and salinity of the water at the sensor, so that we know what the water density is, so that we can turn pressure into water depth more accurately.
A 00s-age Ruskin/RBR CTD
This is why one of the ubiquitous oceanography sensors is the CTD, which stands for Conductivity, Temperature, and Depth. Conductivity of the water is something easily measured, which (through another known and somewhat stable relationship) can be turned into a measure of salinity. The CTD is a package deal to measure accurate depth, bringing temperature and salinity along the way (awesome for an estuarine scientist).
Let me also bring some attention to suspended sediment concentration, or SSC. This is a measure of the density of sediment in the water, often in milligrams of sediment per liter of water. Think of this as "muddiness of the water." The best, most direct way to measure this is to put a liter-sized nalgene bottle in the water and take it to a lab and dry out the sediment and measure its mass. But how do you get a sensor to capture SSC? The technique I've learned is to use an
optical backscatter sensor, which sends out pulses of light and measures how much of the pulse returns to the sensor. In very turbid water, lots of light will reflect back; in very clear water, almost none of it will. These optical sensors produce a turbidity value of the water, which can be measured digitally and continuously (unlike going to take bottle samples). But to turn it into an SSC value, we do need those water samples at known periods in time, and develop calibrations between the turbidity values and SSC values. There's some noise and chaos in this process: the sensors don't necessarily respond exactly linearly to changing turbidities, the backscatter response depends on various properties of the suspended sediment, and you're always making assumptions about how representative your bottle samples are, relative to what the sensor actually sees. And yet we try anyway.
The procedures I described for CTDs work well for "blue-water" oceanography, where the spatial scales are large—boats often send CTDs down 1000s of meters in routine "casts," and the sensors get some maintenance between getting submerged. At these depths, the variations in these properties are stable and large enough that by and large, things work well. (There are a number of folks at
Scripps exploring ways we still need to innovate!) And what I just said about SSC measurement generally works well, especially in systems with stable inputs and dynamics.
But I don't do blue-water oceanography! I do messy coastal oceanography, where depths are often less than 10 meters (often less than 1 meter!) and sometimes the sensors are deployed intertidally, so they get wet during flood tides and go dry during ebbs. The optical sensor now goes in and out of the water, introducing the water-air interface as a possible contributor to its measured backscatter. Mud (or seaweed) can dry to the sensor face, and not wipe off quickly or at all. On top of that, I'm studying
low-gradient landscapes (marshes!), where water flows over the marsh surface may be due to differences in hydraulic head of just a couple centimeters, so precision depth measurements are critical. But then things start to get weird.
With wetting-drying cycles, the premise of a "known and stable" relationship between measured voltage and pressure in the pressure sensor can also fall apart. This is something that requires more research, but what we think is happening is the material properties of the piezometer shift as the temperature changes. In places where the surface air temperature and water temperature can be quite different (consider south San Francisco Bay, where a September day might hit 100°F air temperature but the water is still 60°F), this may be introducing critical small differences in measured output. Consider when a sensor that has become hot over the day is suddenly plunged into cool water, and hasn't come to the assumed thermal equilibrium that underlies how its data get interpreted—a few centimeters of error in depth is the difference between meaningful data and garbage. Unfortunately, the group I work with at the USGS has found that even on an atmospherically stable day with a sensor sitting in a quiescent tank, its calculated depth value still wobbles around a few centimeters. And for a marsh, the entire circulation patterns in flow may be driven by a few centimeters of head difference. So, we've found that in this project, we can't totally deliver on our stated goals. Thankfully, there's much more data for us to pull apart, and we're figuring out methods to reduce these errors in the future.
At the core of this messiness is that we're pushing sensors designed to be 3000 meters deep in relatively homogeneous ocean water to measure marsh water 10 centimeters deep subject to chaotic coastal changes. By pushing many of the underlying assumptions behind how the sensors are made and the kinds of environments they can represent, the magnitudes of our uncertainties are starting to play with the magnitudes of our calculated values.
These complexities, to me, are reminders of how much data aren't collected but are made by a combination of sensors and code and people, all of which run on various assumptions and paradigms that have varying roles on the final number we try so hard to get published.
Turning pressure to depths,
Lukas