Dear Andy
> 'height_above_X' means the vertical distance above the named surface X -
> there are a whole set of these for 'sea_surface_height' ('above_geoid',
> 'above_geopotential_datum', 'above_mean_sea_level') that set the vertical
> reference
Yes.
> Then, as I think we've all agreed, 'due_to_surge', 'due_to_tide' are simply
> relative quantities.
Yes, I agree, such a definition is possible, where due_to_X means the
difference between SSH with X and SSH without X.
> for my surge model, which is referenced to mean sea level and has a tide and
> surge part that I can decompose, I could generate variables with standard
> names:
>
> 1. sea_surface_height_above_mean_sea_level - the total
>
> 2.sea_surface_height_due_to_tide - the tide part
>
> 3. sea_surface_height_due_to_surge - the surge part
And you also said
> a summation of these quantities should lead us to a
> 'sea_surface_height_above_X', but on their own they are generic.
That's not true here, is it? (2) + (3) is not equal to 1. There must be another
term (Z, say) in the sum, for SSH above MSL when there is no tide and no surge.
(1) SSH above MSL = (Z) SSH above MSL with no tide and no surge
+ (2) SSH elevation due to tide + (3) SSH elevation due to surge.
Or maybe what the model produces is Z + 2 i.e. SSH above MSL if there is no
surge? We could call that
sea_surface_height_above_mean_sea_level_assuming_no_surge
Or maybe Z=0? That is what I suggested initially about MSL, in effect.
Which term contains the seasonal cycle of SSH?
> the reference_datum should a) be stipulated and b) have a way of being mapped
> to the reference_ellipsoid we would use for the coordinate system. A) would
> need a new descriptive variable, e.g. 'reference_datum_name'. B) already has
> a precedent in 'water_surface_reference_datum_altitude' but actually using
> the existing 'height_above_reference_ellipsoid' might be more appropriate
> (basically I'm not sure if a
> 'reference_datum_height_above_reference_ellipsoid' is necessary)?
I'm not too keen on the generic reference_datum, and feel it would be better
to add names for the specific datums you use, if they are geophysical surfaces.
If they are arbitrary benchmarks, I agree that some way to name them is needed.
> Hopefully I'm not talking total nonsense.
Of course not. Sorry this is so hard.
Best wishes
Jonathan
> -----Original Message-----
> From: CF-metadata [mailto:[email protected]] On Behalf Of
> Jonathan Gregory
> Sent: 02 May 2018 14:27
> To: [email protected]
> Subject: [CF-metadata] proposed new standard name for storm surge residual
>
> Dear Andy
>
> Thanks for your email. This is surprisingly mind-bending. Although MSL could
> mean time-means on various periods, I believe that when we refer to it as a
> surface in CF standard names we mean a very long-term mean, to get rid of all
> variations. Of course, that's still not well-defined, because on very long
> timescales other things change like climate and ocean basin bathymetry.
>
> I don't think this is the point at issue. What I'm struggling with is whether
> the elevation of the sea surface due to tide has a datum (MSL, reference
> ellipsoid, geoid, etc.) or not. If, like "due to surge", it has no datum, it
> means the difference between SSH with tide and without tide. What does
> "without tide" mean, then? It could mean "with permanent tide but no
> time-varying tide", for instance. If you include a datum you get something
> like "elevation of sea surface above reference elliposid due to tide", but
> I'm not sure what the attribution to tide means in that case. What's the
> difference between this quantity and
> sea_surface_height_above_reference_ellipsoid, which is already a standard
> name? The difference would seem to be the part "due to tide". But that
> returns us to the question of what "without the tide" means.
>
> Best wishes
>
> Jonathan
>
>
>
> ----- Forwarded message from "Saulter, Andrew"
> <[email protected]> -----
>
> > Date: Wed, 25 Apr 2018 07:08:01 +0000
> > From: "Saulter, Andrew" <[email protected]>
> > To: "[email protected]" <[email protected]>
> > Subject: Re: [CF-metadata] proposed new standard name for storm surge
> > residual
> >
> > Thanks Jonathon,
> >
> > From the below:
> >
> > We use the term "sea" - agreed. "due_to_surge" has no need for a datum
> > reference - agreed.
> >
> > MSL implies no tide and no surge. I'd disagree with this; sea level at high
> > frequency will comprise contributions from lots of different components and
> > mean sea level is therefore a quantity where we have chosen to average
> > these effects out as best as possible but they haven't gone away - for
> > example a monthly mean sea level from a coastal tide gauge may still
> > comprise some tidal signal (for example an asymmetry where the equinoxes
> > occur in different months) and will certainly include variation due to a
> > seasonal changes in the surge contribution.
> >
> > So from my perspective, the only difference between tide and surge is that
> > we would expect tide to always reference some form of fixed datum (which is
> > preferably more flexible than just MSL) in order to allow us to construct a
> > sea level series that is vertically referenced, whereas surge and other
> > contributions will be relative quantities.
> >
> > Cheers
> > Andy
> >
> >
> >
> > -----Original Message-----
> > From: CF-metadata [mailto:[email protected]] On Behalf
> > Of Jonathan Gregory
> > Sent: 24 April 2018 18:30
> > To: [email protected]
> > Subject: Re: [CF-metadata] proposed new standard name for storm surge
> > residual
> >
> > Dear Andy
> >
> > > - I'm only going to do this for sea water levels, so from my point
> > > of view using the term "sea" is fine; I'm just aware that what comes
> > > below could be applied in other water bodies
> >
> > Yes. However, we make our job simpler (as a principle in CF) by doing only
> > what we need to for the current use-cases.
> >
> > > - "due_to_surge" will either a) be derived as a residual value
> > > calculated after taking a measured sea level value (referenced to
> > > some fixed datum) and subtracting a predicted tide height
> > > (referenced to same datum), or b) be a quantity that we would expect
> > > to add to a predicted tide height in order to create a total water
> > > level (again referenced to some fixed datum)
> >
> > In both cases the datum is not relevant to the elevation due to surge.
> >
> > > - "due_to_tide" will be the tide values mentioned above which will have
> > > to be referenced against a datum or common benchmark, e.g. chart datum,
> > > mean sea level, Ordnance Datum Newlyn, in order to make sense.
> >
> > ... whereas here the datum *is* required.
> >
> > So these cases seem different after all, and may need different sorts of
> > name - at least, that's my first reaction. It's because there isn't a
> > situation of "no tide", but there is a situation of "no surge". On second
> > thoughts, I'm not sure about this distinction. No tide, I suppose, means
> > MSL. On the other hand, no surge isn't uniquely defined - something must be
> > assumed about the MSLP and the wind when there *isn't* a surge. What is
> > that?
> >
> > > So far these are variables that give us what we might term 'still water
> > > level', i.e. neglecting wave effects. However, thinking about future
> > > requirements you could easily see an extension to higher frequency
> > > parameters such as "due_to_wave_induced_setup" (minutes to hours),
> > > "due_to_run_up" (seconds to minutes), "due_to_waves" (seconds) if you
> > > were looking at a detailed approach to evaluating total water levels. All
> > > these would work like surge, in that these aren't referenced to a datum
> > > themselves but will contribute to some total water level value that does
> > > need to be.
> >
> > Right. If we can work out how to deal with the surge, I agree the others
> > will follow when they are needed.
> >
> > Best wishes
> >
> > Jonathan
> >
> > > Instinctively when I plot summations of these types of variables in
> > > time-series I would write 'sea_surface_elevation' on the y-axis (since
> > > the water goes down as well as up) but that, definitely, is just me!
> > > Personally I have no objection to "elevation_of_sea_surface" either - it
> > > seems clear what it means and if we are all happy that "sea" can be
> > > generic for "water" I'd be good with this.
> > >
> > > Thanks
> > > Andy
> > >
> > >
> > > -----Original Message-----
> > > From: CF-metadata [mailto:[email protected]] On
> > > Behalf Of Jonathan Gregory
> > > Sent: 24 April 2018 17:08
> > > To: [email protected]
> > > Subject: [CF-metadata] Fwd: Re: Fwd: Re: proposed new standard name
> > > for storm surge residual
> > >
> > > Dear Andy
> > >
> > > > "elevation_of_sea_surface_due_to_X" sounds most appropriate.
> > > OK.
> > >
> > > Since we already have
> > > water_surface_height_above_reference_datum
> > > water_surface_reference_datum_altitude
> > > in the table, I agree that water_surface is OK to use. In general in
> > > standard names we have made the word "sea" signify all bodies of water,
> > > as we've not been able to find another neat and clear word for them.
> > > However, we've already departed from that rule in this case. Do you need
> > > to use these names for lakes?
> > > If your use is just sea, I would rather stick to sea names, since we've
> > > got a lot more of those.
> > >
> > > I would say that the reference_datum names should be avoided if your
> > > datum is something that can be geophysically defined, such as
> > > mean_sea_level or the geoid. We have names mentioning those levels, which
> > > are more specific and useful. I think the reference_datum names are for
> > > arbitrary levels, indicated by some physical benchmark.
> > >
> > > I feel that
> > > elevation_of_water|sea_surface
> > > would be better than
> > > water|sea_surface_elevation
> > > because to me the former sounds like "making the water surface higher",
> > > which is what we mean, while the latter means "how high the water surface
> > > is". That is rather subtle and language-dependent, so I'm a bit nervous
> > > about it. It also might just be me! How does it sound to you?
> > >
> > > Best wishes
> > >
> > > Jonathan
> > >
> > > >
> > > > -----Original Message-----
> > > > From: CF-metadata [mailto:[email protected]] On
> > > > Behalf Of Jonathan Gregory
> > > > Sent: 24 April 2018 14:26
> > > > To: [email protected]
> > > > Subject: [CF-metadata] Fwd: Re: proposed new standard name for
> > > > storm surge residual
> > > >
> > > > Dear Andrew and John
> > > >
> > > > I hadn't noticed that sea_surface_elevation is already in use as an
> > > > alias.
> > > > That's a pity, but maybe it would be confusing anyway, given John's
> > > > comment.
> > > >
> > > > I think that what Andrew needs is terms that say how much higher the
> > > > sea surface is because of influence X relative to how high it would be
> > > > in the absence of influence X. Such terms do not need any datum (like
> > > > geoid or MSL). The difference in z is the same regardless of what datum
> > > > would be used for z itself. I suggested before that change_in would be
> > > > a possibility but it doesn't sound quite right, because we aren't
> > > > comparing SSH before and after a storm surge for example, which is what
> > > > I'd understand by "change in SSH due to storm surge". Other ideas:
> > > >
> > > > elevation_of_sea_surface_due_to_X
> > > > increment_to_sea_surface_height_due_to_X
> > > > increase_of_sea_surface_height_due_to_X
> > > >
> > > > What others occur to you?
> > > >
> > > > Best wishes
> > > >
> > > > Jonathan
> > > >
> > > >
> > > > ----- Forwarded message from "Saulter, Andrew"
> > > > <[email protected]> -----
> > > >
> > > > > Date: Tue, 24 Apr 2018 07:17:48 +0000
> > > > > From: "Saulter, Andrew" <[email protected]>
> > > > > To: "[email protected]" <[email protected]>
> > > > > Subject: Re: [CF-metadata] proposed new standard name for storm surge
> > > > > residual
> > > > >
> > > > > John,
> > > > >
> > > > > I see where you are with that, but my understanding from Jonathon
> > > > > Gregory's email earlier is that the 'due_to' part of the phrasing
> > > > > identifies a component process that contributes to an overall
> > > > > quantity. In the case below 'due_to_storm_surge' is a contribution to
> > > > > 'sea_surface_elevation' and that quantity is what needs to be
> > > > > referenced to some datum. Or maybe I'm not getting it? Steep learning
> > > > > curve this...
> > > > >
> > > > > Anyway, having thought about datum's now I have done some further
> > > > > searching and noted the following already exist as standard names:
> > > > >
> > > > > water_surface_height_above_reference_datum - this denotes the
> > > > > quantity
> > > > >
> > > > > water_surface_reference_datum_altitude - references the datum to
> > > > > the
> > > > > (grid_mapping) geoid
> > > > >
> > > > > These look much more like what I was after, so the question is can
> > > > > the 'due_to_storm_surge' and 'due_to_tide' be sensibly appended to
> > > > > 'water_surface_height_above_reference_datum'??
> > > > >
> > > > > Cheers
> > > > > Andy
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Graybeal [mailto:[email protected]]
> > > > > Sent: 23 April 2018 17:57
> > > > > To: Saulter, Andrew <[email protected]>
> > > > > Cc: CF Metadata List <[email protected]>
> > > > > Subject: Re: [CF-metadata] proposed new standard name for storm
> > > > > surge residual
> > > > >
> > > > >
> > > > > I actually find this new name/definition internally inconsistent.
> > > > > An elevation that is ‘due to storm surge’ seems to be relative
> > > > > to the elevation without the storm surge, which makes the datum
> > > > > irrelevant.
> > > > > Unless the change due to the storm surge would be measured
> > > > > differently under different datums, but I can’t imagine that.
> > > > > (Taking the other way, if it’s an elevation relative to some
> > > > > normal datum, then “due to storm surge” is irrelevant.)
> > > > >
> > > > > In any case, under the new definition, the description needs to
> > > > > include exactly how the datum is specified. The computers and people
> > > > > will need to know where to look for that information, and ideally it
> > > > > should be a unique identifier that the computers can recognize and
> > > > > understand.
> > > > >
> > > > >
> > > > > john
> > > > >
> > > > >
> > > > > > On Apr 23, 2018, at 01:43, Saulter, Andrew
> > > > > > <[email protected]> wrote:
> > > > > >
> > > > > > Apologies, a little bit more to add to the below following up
> > > > > > from Jonathon's first email,
> > > > > >
> > > > > > For both tide and surge I would actually prefer to go with
> > > > > > Jonathon's suggestion that the 'height_above_mean_sea_level' part
> > > > > > of my suggestions is replaced with 'elevation'. This is a much more
> > > > > > compact and flexible way of expressing things and means,
> > > > > > particularly with tide that we can reference this to whichever
> > > > > > datum we like (for example Chart Datum, Ordnance Datum, MSL)
> > > > > > dependent on source elsewhere in the metadata. I think it is also
> > > > > > appropriate that we think of "sea_surface_elevation" as a quantity
> > > > > > that can be contributed to via processes with many different
> > > > > > timescales, e.g. tides, surges, individual ocean waves.
> > > > > >
> > > > > > This would take us to:
> > > > > >
> > > > > > Proposed standard name:
> > > > > > sea_surface_elevation_due_to_storm_surge
> > > > > > Units: m
> > > > > > "Sea surface elevation" is a time-varying quantity denoting the
> > > > > > height of the sea surface relative to a given datum. The
> > > > > > specification of a physical process by the phrase “due_to_process”
> > > > > > means that the quantity named is a single term in a sum of terms
> > > > > > which together compose the general quantity named by omitting the
> > > > > > phrase. Storm surge effects, due to meteorological forcing of the
> > > > > > ocean and interaction between the generated surge and tides, are a
> > > > > > significant contributor to the observed sea surface height.
> > > > > >
> > > > > > Proposed standard name:
> > > > > > sea_surface_elevation_due_to_tide
> > > > > > Units: m
> > > > > > "Sea surface elevation" is a time-varying quantity denoting the
> > > > > > height of the sea surface relative to a given datum. The
> > > > > > specification of a physical process by the phrase “due_to_process”
> > > > > > means that the quantity named is a single term in a sum of terms
> > > > > > which together compose the general quantity named by omitting the
> > > > > > phrase. Tides are a significant contributor to the observed sea
> > > > > > surface height; here “tide” denotes a generic variable describing
> > > > > > the time varying tidal signal, for example as generated based on a
> > > > > > summation of harmonically analysed components, or resulting from
> > > > > > the application of such components as boundary conditions to a
> > > > > > numerical tidal model.
> > > > > >
> > > > > > However, I have one concern in that "sea_surface_elevation" is
> > > > > > presently given as an alias for "sea_surface_height_above_geoid".
> > > > > > My worry is that the latter has implications for the vertical datum
> > > > > > and that we might choose to disconnect this from other aspects of
> > > > > > the grid_mapping variable (e.g. where my station positions are in
> > > > > > WGS84, but the vertical reference is to chart datum) in which case
> > > > > > we are not strictly referencing against the geoid any more. In
> > > > > > addition, the term "sea_surface_height" has more usually been
> > > > > > associated with altimeter and model products where high frequency
> > > > > > signals are generally excluded?
> > > > > >
> > > > > > So some consensus as to whether "sea_surface_elevation" is the
> > > > > > phrasing to go for would be very helpful...
> > > > > >
> > > > > > Cheers
> > > > > > Andy
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: CF-metadata [mailto:[email protected]] On
> > > > > > Behalf Of Saulter, Andrew
> > > > > > Sent: 20 April 2018 17:04
> > > > > > To: [email protected]
> > > > > > Subject: Re: [CF-metadata] proposed new standard name for
> > > > > > storm surge residual
> > > > > >
> > > > > > Jonathon, Helen,
> > > > > >
> > > > > > Thanks for the feedback.
> > > > > >
> > > > > > I'd looked at the existing 'sea_surface_height' terms but had the
> > > > > > same worry as Jonathon that the use of 'amplitude' restricted these
> > > > > > to some (unspecified) time integral. What I'm after is definitely a
> > > > > > variable that varies as a function of time. It's also unusual in
> > > > > > the coastal forecasting community to want to split the various
> > > > > > contributions to tide up.
> > > > > >
> > > > > > The 'due_to_air_pressure_and_wind' term captures the primary
> > > > > > meteorological processes that induce surge. However, these do not
> > > > > > capture the effect of tide-surge interaction in shallower waters
> > > > > > (for example the extra surge elevation enhances the speed at which
> > > > > > the tide propagates so a 'surge residual' can include the
> > > > > > propagation speed delta as well as the background super-elevation)
> > > > > > nor other secondary variability that we often see in surge
> > > > > > residuals, such as steric changes of the water column. So I feel
> > > > > > that using a catchall term 'storm_surge', although less specific
> > > > > > would have a lot less potential to mislead a user. The option
> > > > > > exists, I assume, in the comments attribute for a variable to be
> > > > > > more precise about its derivation/generating processes.
> > > > > >
> > > > > > So overall, I couldn't find a goldilocks term for either surge or
> > > > > > tide that would fit my users understanding of the variables - hence
> > > > > > the new suggestions.
> > > > > >
> > > > > > Have a good weekend
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: CF-metadata [mailto:[email protected]] On
> > > > > > Behalf Of Jonathan Gregory
> > > > > > Sent: 11 April 2018 18:37
> > > > > > To: [email protected]
> > > > > > Subject: [CF-metadata] proposed new standard name for storm
> > > > > > surge residual
> > > > > >
> > > > > > Dear Helen and Andy
> > > > > >
> > > > > > I noticed the sea_surface_height_amplitude_due_to_X_tide names as
> > > > > > well, and I wondered, what does "amplitude" mean here? The
> > > > > > definitions of these names don't say, and I feel that we should be
> > > > > > clear. I guessed it might mean the amplitude of SSH due to the
> > > > > > tidal cycle, whereas I think Andy means the actual tidal height as
> > > > > > a function of time. Are you able to clarify?
> > > > > >
> > > > > > It's a good point about due_to_air_pressure[_and_wind], thanks.
> > > > > > That may not obviously mean "storm surge", which maybe could be
> > > > > > inserted in the definition.
> > > > > >
> > > > > > Best wishes
> > > > > >
> > > > > > Jonathan
> > > > > >
> > > > > > ----- Forwarded message from "Snaith, Helen M."
> > > > > > <[email protected]>
> > > > > > -----
> > > > > >
> > > > > >> Date: Tue, 10 Apr 2018 13:14:16 +0000
> > > > > >> From: "Snaith, Helen M." <[email protected]>
> > > > > >> To: "Saulter, Andrew" <[email protected]>
> > > > > >> CC: "[email protected]" <[email protected]>
> > > > > >> Subject: Re: [CF-metadata] proposed new standard name for storm
> > > > > >> surge
> > > > > >> residual
> > > > > >> x-mailer: Apple Mail (2.3445.6.18)
> > > > > >>
> > > > > >> Hi Andy
> > > > > >>
> > > > > >> Many of the sea_surface_height terms have been used in satellite
> > > > > >> altimetry for some time.
> > > > > >> The tidal components have been split out into
> > > > > >> sea_surface_height_amplitude_due_to_equilibrium_ocean_tide<javascript:
> > > > > >> void(0)>
> > > > > >> sea_surface_height_amplitude_due_to_geocentric_ocean_tide<javascript:
> > > > > >> v
> > > > > >> oid(0)>
> > > > > >> sea_surface_height_amplitude_due_to_non_equilibrium_ocean_tid
> > > > > >> e<
> > > > > >> ja
> > > > > >> va
> > > > > >> sc
> > > > > >> r
> > > > > >> ipt:void(0)>
> > > > > >>
> > > > > >> And the pole tide
> > > > > >> sea_surface_height_amplitude_due_to_pole_tide<javascript:void
> > > > > >> (0
> > > > > >> )>
> > > > > >>
> > > > > >> In these terms, amplitude has been used to identify the
> > > > > >> ‘above mean level’ and sea_surface_height is as alias of
> > > > > >> sea_surface_heigth_above_mean_sea_level
> > > > > >>
> > > > > >>
> > > > > >> Also included are the terms
> > > > > >> sea_surface_height_correction_due_to_air_pressure_and_wind_at
> > > > > >> _h
> > > > > >> ig
> > > > > >> h_
> > > > > >> fr
> > > > > >> e
> > > > > >> quency<javascript:void(0)>
> > > > > >> sea_surface_height_correction_due_to_air_pressure_at_low_freq
> > > > > >> ue
> > > > > >> nc
> > > > > >> y<
> > > > > >> ja
> > > > > >> v
> > > > > >> ascript:void(0)>
> > > > > >>
> > > > > >> The former of which is related to surge I think - it is normally
> > > > > >> determined from a tidal model and is the response of sea level to
> > > > > >> changes in air pressure and wind.
> > > > > >>
> > > > > >> Even if these are not the correct terms, as you are not
> > > > > >> determining a 'correction’ but a value - they should be related to
> > > > > >> the surge components, so do they give the ‘due to’ component you
> > > > > >> need?
> > > > > >>
> > > > > >> Helen
> > > > > >>
> > > > > >>
> > > > > >> On 4 Apr 2018, at 17:13, Saulter, Andrew
> > > > > >> <[email protected]<mailto:[email protected]>>
> > > > > >> wrote:
> > > > > >>
> > > > > >> Dear all,
> > > > > >>
> > > > > >> First posting to this list, so please forgive me if I’m doing
> > > > > >> it wrong…
> > > > > >>
> > > > > >> I’d like to request an addition to the standard name list to
> > > > > >> include storm surge residual and tide. These variables are
> > > > > >> generated for the purpose of coastal flood prediction and will be
> > > > > >> available in future, netCDF based, operational products from the
> > > > > >> Met Office.
> > > > > >>
> > > > > >> Proposed standard name:
> > > > > >> sea_surface_height_above_mean_sea_level_due_to_storm_surge
> > > > > >> Units: m
> > > > > >> "Sea surface height" is a time-varying quantity. "Height_above_X"
> > > > > >> means the vertical distance above the named surface X. "Mean sea
> > > > > >> level" means the time mean of sea surface elevation at a given
> > > > > >> location over an arbitrary period sufficient to eliminate the
> > > > > >> tidal signals. The specification of a physical process by the
> > > > > >> phrase “due_to_process” means that the quantity named is a single
> > > > > >> term in a sum of terms which together compose the general quantity
> > > > > >> named by omitting the phrase. Storm surge effects, due to
> > > > > >> meteorological forcing of the ocean and interaction between the
> > > > > >> generated surge and tides, are a significant contributor to the
> > > > > >> observed sea surface height.
> > > > > >>
> > > > > >> Proposed standard name:
> > > > > >> sea_surface_height_above_mean_sea_level_due_to_tide
> > > > > >> Units: m
> > > > > >> "Sea surface height" is a time-varying quantity. "Height_above_X"
> > > > > >> means the vertical distance above the named surface X. "Mean sea
> > > > > >> level" means the time mean of sea surface elevation at a given
> > > > > >> location over an arbitrary period sufficient to eliminate the
> > > > > >> tidal signals. The specification of a physical process by the
> > > > > >> phrase “due_to_process” means that the quantity named is a single
> > > > > >> term in a sum of terms which together compose the general quantity
> > > > > >> named by omitting the phrase. Tides are a significant contributor
> > > > > >> to the observed sea surface height; here “tide” denotes a generic
> > > > > >> variable describing the time varying tidal signal, for example as
> > > > > >> generated based on a summation of harmonically analysed
> > > > > >> components, or resulting from the application of such components
> > > > > >> as boundary conditions to a numerical tidal model.
> > > > > >>
> > > > > >> Many thanks
> > > > > >> Andy
> > > > > >>
> > > > > >>
> > > > > >> Andy Saulter
> > > > > >> Surge, Waves and Metocean Projects Manager Met Office FitzRoy
> > > > > >> Road Exeter Devon EX1 3PB
> > > > > >> Tel: +44 (0)1392 884703 Fax: +44 (0)1392 885681
> > > > > >> [email protected]<mailto:andrew.saulter@metoffi
> > > > > >> ce
> > > > > >> .g
> > > > > >> ov
> > > > > >> .u
> > > > > >> k
> > > > > >>> http://www.metoffice.gov.uk<http://www.metoffice.gov.uk/>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> This message has been scanned for viruses and dangerous
> > > > > >> content by MailScanner<http://www.mailscanner.info/>, and is
> > > > > >> believed to be clean.
> > > > > >> _______________________________________________
> > > > > >> CF-metadata mailing list
> > > > > >> [email protected]<mailto:[email protected]>
> > > > > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > > > >>
> > > > > >> ________________________________ This message (and any
> > > > > >> attachments) is for the recipient only. NERC is subject to the
> > > > > >> Freedom of Information Act 2000 and the contents of this email and
> > > > > >> any reply you make may be disclosed by NERC unless it is exempt
> > > > > >> from release under the Act. Any material supplied to NERC may be
> > > > > >> stored in an electronic records management system.
> > > > > >> ________________________________
> > > > > >
> > > > > >> _______________________________________________
> > > > > >> CF-metadata mailing list
> > > > > >> [email protected]
> > > > > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > > > >
> > > > > >
> > > > > > ----- End forwarded message -----
> > > > > > _______________________________________________
> > > > > > CF-metadata mailing list
> > > > > > [email protected]
> > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > > > > _______________________________________________
> > > > > > CF-metadata mailing list
> > > > > > [email protected]
> > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > > > > _______________________________________________
> > > > > > CF-metadata mailing list
> > > > > > [email protected]
> > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > > >
> > > > > _______________________________________________
> > > > > CF-metadata mailing list
> > > > > [email protected]
> > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > >
> > > > ----- End forwarded message -----
> > > > _______________________________________________
> > > > CF-metadata mailing list
> > > > [email protected]
> > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > > _______________________________________________
> > > > CF-metadata mailing list
> > > > [email protected]
> > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > >
> > > ----- End forwarded message -----
> > > _______________________________________________
> > > CF-metadata mailing list
> > > [email protected]
> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > _______________________________________________
> > > CF-metadata mailing list
> > > [email protected]
> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > [email protected]
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > _______________________________________________
> > CF-metadata mailing list
> > [email protected]
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> [email protected]
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> [email protected]
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> [email protected]
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
