I'm trying out data assimilation and a question regarding in-situ profiles came up.
Do we have to consider dynamic height anomalies when assimilating CTD profiles into ROMS, i.e. do you adjust the "depth" axis with each individual salinity and temperature profile from the cast?
In the past week I've tried to find literature on the topic, and while a found tons of assimilation papers using CTDs in general, none of them explains exactly what the term "depth" means.
"obs_depth" in ROMS is "depth of observations below the sea surface", whereas "depth" in a CTD archive means some vertical coordinate "z" calculated from pressure at fixed S,T using some atmospheric pressure value as boundary condition and using some EOS (which one exactly is not my question).
For example EN4 [4] is distributed with a depth dimension, and I can't find info on how they obtain it. For WOA/WOD, [3] states that "... we calculated depth using the UNESCO algorithm for standard ocean" (FAQ question 25)".
"Standard ocean" means to fix S and T (if I understood correctly what I've read so far), and use some EOS to convert pressure to depth, e.g. using equation 25 of [1] (or more recently the function in [2], but again, which EOS to choose in not the question I have).
So if I understand correctly, they neglect the (\Delta D), associated with the dynamic height in equation 25 of [1].
On a side note (not directly my question, but mayby this explains my confusion), I don't understand why they compute and distribute depth instead of pressure, which is usually the quantity that's measured. Converting to depth entangles p with S and T, and even if they assume fixed standard values for S and T, the EOS itself varied several times in the past decades. However, I'm sure they have very good reasons for it, but it's still confusing for a beginner. Also, I downloaded profiling float data directly from ARGO, and they have pressure, so that's more unambiguous. But in the ROMS assimilation tutorials you use EN3, which is distributed with depth.
I guess the dynamic height is on the order of meter in magnitude, and since the data is "aligned" at the surface, the accumulated error gets large only in deep depths (order 1000m) (?). See e.g. tables 2.7 and 2.8 in [5].
Is this right? Is this why nobody converts the "standard depth" (fixed S,T) to actual depth? Or is it converted, but nobody explicitly mentions it?
When the profiles are used to construct mean dynamic topographies, they use the dynamic height, so it feels weired to not do the same when assimilating the profile into the model. Isn't this an artifical bouyancy source/sink?
[1] Fofonoff, N. P., & Millard Jr, R. C. (1983). Algorithms for the computation of fundamental properties of seawater.
[2] https://www.teos-10.org/pubs/gsw/html/gsw_z_from_p.html
[3] https://www.nodc.noaa.gov/OC5/WOD/wod-woa-faqs.html
[4] https://www.metoffice.gov.uk/hadobs/en4/
[5] "Processing of oceanographic station data" https://unesdoc.unesco.org/ark:/48223/pf0000090489
Vertical coordinate for assimilation of CTDs
Re: Vertical coordinate for assimilation of CTDs
Looking at the code in extract_obs.F, what I wrote above
Do I understand correctly that the varinfo.yaml is out of date, because it says there:
Should this be: "depth relative to geoid" instead?
If a negative obs_depth (i.e. a z-Value) is supplied, it is interpolated to fractional levels in extract_obs3d() based on the z_u/z_v/z_rho coordinates on which the variables lives. For example, temp lives on z_rho. But z_rho is not "depth below sea level", instead it is "depth relative to geoid". Is that right?
Would it make sense to account for a (filtered) zeta, for people who want to put observations at a "depth below sealevel"?
Is it true that there are 3 different "heights" one may be interested in:
*) depth below surface (use case is e.g. assimilation of foundation surface temperature, at X meters depth below surface, which would need to account for zeta)
*) height above ground (e.g. moorings)
*) pressure (CTDs, so one would only have to compute potential temperature in the pre-processing stage, but not "depth". May also be advantageous for gliders etc. with a pressure sensor but no measured S,T,p profile above the instrument, in which case one would have to resort to climatologies)
Does this make any sense?
is not true, is it?"obs_depth" in ROMS is "depth of observations below the sea surface"
Do I understand correctly that the varinfo.yaml is out of date, because it says there:
Code: Select all
variable: obs_depth
standard_name: depth_of_observation_below_sea_surface
If a negative obs_depth (i.e. a z-Value) is supplied, it is interpolated to fractional levels in extract_obs3d() based on the z_u/z_v/z_rho coordinates on which the variables lives. For example, temp lives on z_rho. But z_rho is not "depth below sea level", instead it is "depth relative to geoid". Is that right?
Would it make sense to account for a (filtered) zeta, for people who want to put observations at a "depth below sealevel"?
Is it true that there are 3 different "heights" one may be interested in:
*) depth below surface (use case is e.g. assimilation of foundation surface temperature, at X meters depth below surface, which would need to account for zeta)
*) height above ground (e.g. moorings)
*) pressure (CTDs, so one would only have to compute potential temperature in the pre-processing stage, but not "depth". May also be advantageous for gliders etc. with a pressure sensor but no measured S,T,p profile above the instrument, in which case one would have to resort to climatologies)
Does this make any sense?