Hi again,
addendum to my previous message: Nan was asking what the best way to provide
information needed to compute sound speed was. My previous lengthy answer was
essentially, "don't provide sound speed".
If you wanted to ignore this well-intentioned advice and provide sound speed,
I'd say you need to:
- provide the water depth you used (e.g. in the bounds attribute)
- indicate in cell_methods that you have a harmonic mean in the Z direction
(right now, I can see "mean" but not "harmonic_mean" in the list of possible
cell_methods - this list would have to be amended, I suppose)
If you wanted to let the users do it themselves, you should give them a way to
figure out the water depth, by indicating everything you know about where you
deployed the instrument (e.g. in the comment attribute, "Instrument deployed
at site where echo sounder showed 2885m water depth using sound speeds
corrected with nearby CTD data. Sounded depth uncertainty estimated as
+-10m.")
Matthias
On Wednesday, October 09, 2013 11:32:07 am Matthias Lankhorst wrote:
> Hi Nan,
>
> here is my explanation for your sound speed question...
>
> My application is an IES instrument, which sits still on the seafloor and
> pings upward. The travel times measured vary by minute amounts based
> primarily on the temperature of the water column, i.e. the data are
> primarily a proxy of heat content of the water. Obviously, the overall
> value of travel time depends on the water depth, but that does not change
> since the instrument does not move.
>
> In comparison, a ship echo sounder pings downward, assumes some constant
> sound speed (usually 1500 m/s) and uses the travel time to determine water
> depth. In the ship's case, sound speed fluctuations due to temperature
> changes are usually negligible, at least for the purpose of navigation.
>
> Either way, the property measured is the acoustic travel time between
> seafloor and sea surface.
>
> Now on to sound speed: the sound speed in either case is the water depth
> divided by the measured travel time. This sounds simple, but has two
> important glitches:
>
> (1)
> You don't know the exact water depth in either case, so you are stuck with
> one measurement (travel time) and two unknowns (water depth and sound
> speed). For the ship application, they assume a known sound speed and
> determine water depth to an accuracy that does the job for navigation. For
> the IES, you at least know that water depth is constant, but you can only
> guess what it is from whatever you know about your deployment location
> (that's why I call the measurement a "proxy", rather than an absolute
> measure, of heat content).
>
> (2)
> The real sound speed varies with depth. The sound speed that you derive
> from "water depth divided by travel time" is some kind of vertical
> average. It turns out that this average is not the *arithmetic* mean, but
> rather the *harmonic* mean over the vertical distribution of sound speed.
> Probably doesn't matter, but would have to be documented properly if you
> were to distribute such data.
>
> To avoid all of this confusion, my approach is to report only the property
> that is actually measured (travel time), and let the user figure out what
> assumptions to make to get at sound speed, water depth, heat content,
> whatever.
>
> My advice is for you to do the same, i.e. stay away from sharing the sound
> speeds, but rather share only what you actually measure.
>
> Matthias
>
>
>
> On Wednesday, October 09, 2013 04:40:37 am cf-metadata-request at cgd.ucar.edu
>
> wrote:
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 8 Oct 2013 17:15:56 +0100
> > From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > To: cf-metadata at cgd.ucar.edu
> > Subject: Re: [CF-metadata] standard_name for acoustic travel time from
> >
> > echo sounder
> >
> > Message-ID: <20131008161556.GB28696 at met.reading.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Dear Nan
> >
> > "sum" is the correct cell_methods to indicate that a quantity applies to
> > the whole extent of a cell i.e. it is extensive, rather than intensive.
> > It does not necessarily mean that values were actually added up. For
> > instance, "sum" would be the cell_methods for a precipitation amount
> > accumulated within a time-interval.
> >
> > Best wishes
> >
> > Jonathan
> >
> > ----- Forwarded message from Nan Galbraith <ngalbraith at whoi.edu> -----
> >
> > > Date: Tue, 8 Oct 2013 11:20:18 -0400
> > > From: Nan Galbraith <ngalbraith at whoi.edu>
> > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0)
> > >
> > > Gecko/20130801 Thunderbird/17.0.8
> > >
> > > To: cf-metadata at cgd.ucar.edu
> > > Subject: Re: [CF-metadata] standard_name for acoustic travel time from
> > > echo sounder
> > >
> > >
> > >
> > > Hi All -
> > >
> > >
> > >
> > > Can someone please answer this question? There must be analogies in
> > > the atmospheric community, but I don't know of anyone putting this kind
> > > of ocean data into CF.
> > >
> > >
> > >
> > > What is the best way to provide the information needed to extract the
> > > geophysical quantity sound speed from the measured quantity of signal
> > > travel time?
> > >
> > >
> > >
> > > It has been proposed to be done with cell_methods='Z:sum', or with
> > > a coordinate reference frame that includes the orientation of the
> > > instrument.
> > > Is there a 'best practice' for this?
> > >
> > >
> > >
> > > Thanks - Nan
> > >
> > > On 6/7/13 3:57 PM, Nan Galbraith wrote:
> > > >Hi Matthias and all -
> > > >
> > > >Are cell methods the right way to document this? The 'sum' cell
> > > >method indicates
> > > >that you've summed a number of measurements, and I don't think
> > > >that's the case
> > > >here.
> > > >
> > > >I'd have thought that providing the the instrument depth and
> > > >orientation (upward)
> > > >would make it more clear.
> > > >
> > > >This isn't a feature I use routinely, so I could easily be missing
> > > >something.
> > > >
> > > >Cheers - Nan
> > > >
> > > >On 5/30/13 6:12 PM, Matthias Lankhorst wrote:
> > > >>Hi,
> > > >>
> > > >>thanks already for these comments. Roy's suggested name sounds
> > > >>pretty to my
> > > >>ears.
> > > >>
> > > >>Trying to explain my "cell_methods" thing:
> > > >>
> > > >>The instrument is sitting at a fixed spot on the seafloor, so
> > > >>unlike the echo
> > > >>sounder on a ship, the distance does not change (well, there are
> > > >>tides, but we
> > > >>filter them out). The remaining signal variance is variability in
> > > >>environmental sound speed, which is mostly a measure of sea
> > > >>water temperature.
> > > >>
> > > >>The data, although measured by an instrument at one spot, are
> > > >>dependent on the
> > > >>vertical distance that the acoustic signal travels, i.e.
> > > >>represent some space
> > > >>other than a single point. Chapter 7 of the CF document that I
> > > >>found online
> > > >>explains it this way: "When gridded data does not represent the
> > > >>point values
> > > >>of a field but instead represents some characteristic of the
> > > >>field within
> > > >>cells of finite "volume," a complete description of the variable
> > > >>should include metadata that describes the domain or extent of each
> > > >>cell..."
> > > >>
> > > >>In my example, let us assume my IES sits at 4500m depth looking up.
> > > >>The acoustic signal travel time (roundtrip) will be about 6 seconds
> > > >>(sound speed
> > > >>is ca. 1500 m/s). My data will be numbers that are closer to 5.9
> > > >>seconds if it
> > > >>is warm (faster sound speed), and more like 6.1 seconds if it is
> > > >>cold.
> > > >>
> > > >>If my instrument were instead sitting in the same body of water
> > > >>at 3000m depth
> > > >>(let's assume there is a mountain nearby), all of my numbers would be
> > > >>something close to 4 seconds. Now... I don't want the user to
> > > >>think I am still
> > > >>in 4500m depth in outrageously hot water!
> > > >>
> > > >>Bottom line: I need to tell the user what depth range I am
> > > >>covering (0-4500 or
> > > >>0-3000), and in my limited understanding of the situation this
> > > >>is done via the
> > > >>cell_methods and cell_bounds attributes.
> > > >>
> > > >>Best wishes, Matthias
> > > >>
> > > >>On Thursday, May 30, 2013 09:49:29 am Lowry, Roy K. wrote:
> > > >>>Hi John,
> > > >>>
> > > >>>Not exactly. The travel time in both water column echosounding and
> > > >>>seismics is a proxy for distance and therefore provides
> > > >>>information on the
> > > >>>vertical distribution of returned signal intensity.
> > > >>>
> > > >>>Cheers, Roy.
> > > >>>
> > > >>>________________________________________
> > > >>>From: John Graybeal [graybeal at marinemetadata.org]
> > > >>>Sent: 30 May 2013 15:22
> > > >>>To: Lowry, Roy K.
> > > >>>Cc: mlankhorst at ucsd.edu; cf-metadata at cgd.ucar.edu
> > > >>>Subject: Re: [CF-metadata] standard_name for acoustic travel
> > > >>>time from echo
> > > >>>
> > > >>> sounder
> > > >>>
> > > >>>+1 for Roy's choice.
> > > >>>
> > > >>>Can you explain the following for the acoustically naive? "I assume
> > > >>>the data would need some additional description to denote the
> > > >>>vertical extent
> > > >>>of the measurement, such as cell_bounds and cell_methods='Z:sum'."
> > > >>>
> > > >>>John
> > > >>>
> > > >>>On May 30, 2013, at 06:45, "Lowry, Roy K." <rkl at bodc.ac.uk> wrote:
> > > >>>>Dear All,
> > > >>>>
> > > >>>>Of Matthias's suggestions I have a strong preference for a slight
> > > >>>>extension of roundtrip_acoustic_travel_time_in_sea_water, namely
> > > >>>>acoustic_signal_roundtrip_travel_time_in_sea_water. 'two-way' is a
> > > >>>>possible alternative to 'roundtrip' but I think the former carries
> > > >>>>unfortunate seismic semantic implications, so 'roundtrip' is
> > > >>>>better for
> > > >>>>IES. Including 'in_sea_water' is also essential to clearly
> > > >>>>distinguish
> > > >>>>it from seismic data.
> > > >>>>
> > > >>>>Cheers, Roy.
> > > >>>>________________________________________
> > > >>>>From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of
> > > >>>>Matthias Lankhorst [mlankhorst at ucsd.edu] Sent: 30 May 2013 13:16
> > > >>>>To: cf-metadata at cgd.ucar.edu
> > > >>>>Subject: [CF-metadata] standard_name for acoustic travel
> > > >>>>time from echo
> > > >>>>sounder
> > > >>>>
> > > >>>>Dear CF,
> > > >>>>
> > > >>>>I have oceanographic data from IES instruments (inverted echo
> > > >>>>sounder) that I would like to publish via OceanSITES in a
> > > >>>>CF-compliant form. The
> > > >>>>data in question are acoustic travel times from the echo sounding
> > > >>>>device. This means the time it took for the acoustic signal
> > > >>>>to run from
> > > >>>>the instrument (which sits on the seafloor) to the sea
> > > >>>>surface and back
> > > >>>>to the instrument. These data are commonly used as a proxy for
> > > >>>>ocean heat content.
> > > >>>>
> > > >>>>I don't think there is a suitable CF standard_name out
> > > >>>>there, and ask for
> > > >>>>your help in finding/creating one. Which of the following sound
> > > >>>>good?
> > > >>>>
> > > >>>>acoustic_travel_time
> > > >>>>vertical_acoustic_travel_time
> > > >>>>roundtrip_acoustic_travel_time_in_sea_water
> > > >>>>echo_sounder_acoustic_travel_time
> > > >>>>
> > > >>>>...I could think of a couple more combinations using the
> > > >>>>words above, but
> > > >>>>would like to hear other people's opinions.
> > > >>>>
> > > >>>>The canonical units would obviously be seconds.
> > > >>>>
> > > >>>>I assume the data would need some additional description to denote
> > > >>>>the vertical extent of the measurement, such as cell_bounds and
> > > >>>>cell_methods='Z:sum'.
> > > >>>>
> > > >>>>Any comments?
> > > >>>>
> > > >>>>Kind regards, Matthias
--
_______________________________________
Dr. Matthias Lankhorst
Scripps Institution of Oceanography
9500 Gilman Drive, Mail Code 0230
La Jolla, CA 92093-0230
USA
Phone: +1 858 822 5013
Fax: +1 858 534 9820
E-Mail: mlankhorst at ucsd.edu
http://www-pord.ucsd.edu/~mlankhorst/
Received on Wed Oct 09 2013 - 12:50:58 BST
