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
> >
> >
> >
> >
> > --
> > *******************************************************
> > * Nan Galbraith Information Systems Specialist *
> > * Upper Ocean Processes Group Mail Stop 29 *
> > * Woods Hole Oceanographic Institution *
> > * Woods Hole, MA 02543 (508) 289-2444 *
> > *******************************************************
> >
> >
--
_______________________________________
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:32:07 BST
