Closed GoogleCodeExporter closed 8 years ago
Hard to tell exactly what is happening without seeing data, but I expect that what you're describing is the classic "salinity" spiking, that can arise from things like:
Such issues are quite well known to oceanographers that use CTD data, and a large processing effort is typically involved to remove the so-called "spikes". There are resources available on the web (see e.g. the SeaBird data processing manual), and in a large number of journal articles.
The problem arises when using the Gibbs SeaWater toolbox of TEOS10. The IMOS toolbox uses its code to derive salinity from tempreature, pressure and conductivity. Sometimes, while neither temperature, pressure nor conductivity are showing any important change, we can see that the GSW computes a value of salinity that would suddenly spike for no obvious reason. Will try to post an example of data.
Yes, what you're describing sounds exactly like the issues I described above, and isn't a problem with the TEOS-10 salinity calculation per se, but rather with the difficulties inherent in calculating salinity from conductivity and temperature (and pressure, though its effects are smaller).
Essentially, about 90% of the conductivity variation is actually due to temperature, and only 10% due to salinity. To get salinity from the conductivity we have to remove the variations due to temperature. That means that slight errors in either C or T, or more commonly slight lags between them (either because of sensors located at different places on the instrument, or lags due to the pumping system) can have a big effect on the calculated salinity, leading to spiking.
I can demonstrate the effect with synthetic profiles. Below I've prescribed a temperature (far left) and salinity (far right) profile, with an interface (i.e. pycnocline) at mid-depth. The actual conductivity profile (calculated using gsw_C_from_SP
) is in the middle.
Now, if we offset the conductivity by some number of samples, say -10, and then recalculate salinity using gsw_SP_from_C
we get a different looking salinity, even though T and C are still "smooth":
A similar, but opposite, effect happens if conductivity is lagged by +10 samples:
If we look at the effect of the lag on salinity as we go from -10 to +10, the effect is quite dramatic:
As a result, much of "standard" CTD processing involves lagging, smoothing, and correcting the C and T profiles to produce the best estimate of salinity, before then doing some kind of "bin" averaging to prescribed pressure levels.
Apologies if I've described something that you already know about, and are in fact referring to something different here.
Thank you for these detailed explanations. I had noticed this phenomena on a timeserie and as far I can remember I hadn't notice it was crossing an interface. I guess that could happen anyway. Next time I see this I'll try to update this post with more info.
You're welcome @ggalibert!
As another example, consider what happens when the "time constant" of the temperature and conductivity are not matched. For a thermistor, the "time constant" represents the amount of time that it takes for a change in water temperature to be registered by the sensing element. It is controlled by the housing of the thermistor (i.e. how thick it is), and also the speed at which water is flowing past (which effectively controls the rate of transfer of heat through the turbulent boundary layer next to the sensor).
On the other hand, a change in conductivity is sensed nearly instantaneously (at least, if you ignore thermal inertia of the conductivity cell), meaning that the two sensors have differing response times in changing conditions.
To illustrate, I took the same theoretical profiles from above, but ran the temperature through a filter that simulates what would happen if the response time of the thermistor was 1s (note I've assumed the fall speed is 0.5 m/s).
Note that again we produce a salinity "spike" similar in form to when we simply lagged the series.
excellent explanation.
Original issue reported on code.google.com by
guillaum...@gmail.com
on 11 Nov 2014 at 5:46