Dear Andy Thanks for this, and to Roy for support. I agree, I think we've pretty much worked out what we mean now.
Instead of chart_datum I would prefer that we had standard names mentioning the specific datums you want e.g. lowest_astronomical_tide, because it is more informative and reduces the need for other information. Or is there a need to be vague about it? We have a mechanism, viz grid_mapping, to identify datums more precisely. If we can't do that currently for MSL we could extend the convention. As well as steric changes, I think non-tidal includes ocean dynamics (on all timescales). I think your definitions look right. Best wishes Jonathan ----- Forwarded message from "Saulter, Andrew" <[email protected]> ----- > Date: Tue, 8 May 2018 08:08:13 +0000 > From: "Saulter, Andrew" <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [CF-metadata] proposed new standard name for storm surge > residual > > Dear Jonathon, > > Thanks for all the constructive inputs - this feels like we are getting > somewhere :-) > > I'd be very happy with "non_tidal_elevation_of_sea_surface_height"; elevation > references positive when SSH is increased but also acknowledges suppression > of SSH with high pressure/negative surge; non-tidal gives us the very useful > catchall that there are various processes at play. > > Regards the tidal SSH, you are absolutely right about assumptions. Normally > the tidal predictions we would be using (either directly or as boundary > inputs to a model) would be derived from a harmonic analysis of data covering > a given averaging period (varies, but anything from a month as a minimum that > captures a single spring-neap cycle, to 19-odd years to capture a full set of > sun-moon variations that cause the very largest tides). It is generally > assumed that the averaging will cancel out many of the other ocean effects - > any errors where this hasn't happened correctly will manifest themselves in > the non_tidal part (which is why I'm comfortable that this name makes more > sense than surge for observed values). > > Being the wild optimist that I am, I've taken the below and tried to flesh it > out a bit for the tide and non-tidal variables we would have in our use > cases. Please let me know what you reckon - the descriptions might still need > some work? > > tidal_sea_surface_height_above_mean_sea_level > 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 tidal component of sea surface > height describes the predicted variability of the sea surface due to > astronomic forcing (chiefly lunar and solar cycles) and shallow water > resonance of tidal components; for example as generated based on harmonic > analysis, or resulting from the application of harmonic tidal series as > boundary conditions to a numerical tidal model. > > tidal_sea_surface_height_above_chart_datum > Units: m > "Sea surface height" is a time-varying quantity. "Height_above_X" means the > vertical distance above the named surface X. "Chart datum" describes a local > vertical reference from which depths displayed on a nautical chart are > measured and which differs from mean sea level. For example, chart datum > based on "lowest astronomical tide" or "mean lower low water". The tidal > component of sea surface height describes the predicted variability of the > sea surface due to astronomic forcing (chiefly lunar and solar cycles) and > shallow water resonance of tidal components; for example as generated based > on harmonic analysis, or resulting from the application of harmonic tidal > series as boundary conditions to a numerical tidal model. > > non_tidal_elevation_of_sea_surface_height > Units: m > "Sea surface height" is a time-varying quantity. The "non_tidal_elevation" of > sea surface height describes the contribution made by processes other than > astronomic forcing of the ocean and shallow water resonance of tidal > components. These processes include storm surge effects, due to > meteorological forcing of the ocean and interaction between the generated > surge and tides, steric changes in the water column and, at higher > frequencies, effects of surface ocean waves. The contribution of these > processes vary according to the averaging time of the variable as described > by the "time_bounds" attribute. > > Reading around on vertical datum a little more, the "above_mean_sea_level" > example should cover Ordnance Datum Newlyn (a MSL covering a specified period > at Newlyn and used as the UK's vertical reference) whilst "above_chart_datum" > should cover the LAT based predictions used for navigation in UK waters - > just need to specify these via "time_bounds" or "comment" attributes I think? > > Cheers > Andy > > > > > > > > > > "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. > > -----Original Message----- > From: CF-metadata [mailto:[email protected]] On Behalf Of > Jonathan Gregory > Sent: 04 May 2018 19:40 > To: [email protected] > Subject: Re: [CF-metadata] proposed new standard name for storm surge residual > > Dear Andy > > Thanks for this. I have few comments to add because our thoughts are pretty > much the same, I'm glad to say. > > I am a bit uncomfortable with the phrase "SSH due to X" anyway, because SSH > has no meaning except wrt a datum, not in an absolute sense. The phrase "due > to X" > aptly describes contributions to something which could be zero in an absolute > sense, so you can add up all the contributions to get the whole. > > SSH is a fairly precise geophysical quantity (the level of the interface > between air and water) - although not quite precise! - but as you say, the > value it takes depends on the meaning period. CF describes meaning periods > with time-bounds, so that's no problem. > > "Residual" is maybe slightly jargon. We could spell it out more plainly. > I would suggest > > sea_surface_height_above_X = tidal_sea_surface_height_above_X + > non_tidal_elevation_of_sea_surface_height > > Sometimes sea surface elevation is a synonym of sea surface height, but I > hope that "elevation of SSH" obviously means making SSH higher - does it to > you? > Alternatively, "increase in SSH" might be better. I assume that this term > must include the seasonal non-tidal variation in SSH (due to the seasonal > cycle in ocean dynamics, density and mass). > > I still have a query about the tidal SSH above X. It must include assumptions > for all the other effects - a particular surface pressure, surface winds, > ocean currents, etc. What are they? Perhaps they are all assumed to be annual > mean climatological values. > > Best wishes > > Jonathan > > > ----- Forwarded message from "Saulter, Andrew" > <[email protected]> ----- > > > Date: Fri, 4 May 2018 08:15:00 +0000 > > From: "Saulter, Andrew" <[email protected]> > > To: "[email protected]" <[email protected]> > > Subject: Re: [CF-metadata] proposed new standard name for storm surge > > residual > > > > Dear Jonathon, > > > > Thought I was so close... :-) > > > > But concerned that I am missing something, so I could do with some > > clarification before suggesting another iteration. So please can you > > comment on the below. > > > > The thing that I am failing to understand is the relationship between > > sea_surface_height and the components that should make it up. So here is > > what I think I know: > > > > 1. sea_surface_height should always be related to some vertical datum (MSL, > > geoid, arbitrary reference) in order to be useful. > > > > 2. sea_surface_height is a time-varying quantity so must be made up of > > a whole load of components (tide, steric effects, surge, ocean waves) > > - and the parameter name/description is vague enough that how we > > define this ends up in the eye of the beholder a bit; so a climate > > scientist working with deep ocean data might choose a long temporal > > averaging period that reduces sea surface height variations to > > seasonal and longer effects only, whilst I'd be using a 15 minute > > averaging period with my estimates so will need to include tide and > > surge > > > > 3. at some point the sum of these components must include an offset (Z) > > that makes sea_surface_height relative to its vertical datum. This is where > > the problem seems to lie in our discussion so far. For my users the answer > > is simple - the referencing is included in the tide values and all other > > components are relative. For the model tide and MSL case this becomes > > simplified as Z=0 and the tide rises and falls around this point, but for > > lowest astronomic tide as a datum then we either need to consider Z as some > > finite value or understand that the tide component will nearly always be > > positive ('cos you don't get much lower than lowest astronomic tide). > > > > 4. If you go with idea that tide is referenced against a datum, which > > I is really what I need to do in order to give my users a > > straightforward dataset, then this implies that tide values should > > link to a specific sea_surface_height_above_X (i.e. I can't link a > > tide referenced against LAT with an SSH referenced against MSL) > > > > Its these last two points where 'due_to' implying a relative quantity is > > messing with my mind. From our conversations, I get than sense that > > 'due_to' really implies that any component process we define should be > > transferable universally between different sea_surface_height_above_Xs, and > > that this is because there is another value that defines what Z is. For > > this to work for tide and surge, this should actually mean that 'due_to' > > implies 'relative to MSL for any processes occurring on a higher frequency > > than the MSL definition'? > > > > If that is the case, then 'due_to' will work fine for surge (which is a > > transferable quantity) but not for tide in the context I want to use it in. > > So do we actually need something like: > > > > sea_surface_height_above_X = tidal_sea_surface_height_above_X + > > sea_surface_height_due_to_surge > > > > The other question arising from our discussions is the use of the word > > 'surge'. I'd originally proposed this as it’s a terminology my users will > > understand, but perhaps its not specific enough for the purposes of CF > > and/or I should describe it better. In observation terms, surge is nearly > > always 'what I get when I subtract a tidal prediction from my observed sea > > surface height'. This includes a myriad of effects, from the meteorological > > forced variations (seasonal, daily, the lot), to the tide-surge interaction > > effects and the errors inherent in the tidal predictions; on this basis > > 'non tidal residual of sea surface height' is a more precise description, > > its just that we use the surge label because surge is generally expected to > > be the dominant effect. When we model, life is a lot neater and surge is > > more simply a combination of the met and tide-surge interactions and we > > call our model a 'surge model' rather than a 'NTROSSH model' as a result! > > > > Thinking this through, I'd be comfortable with using 'non_tidal_residual' > > instead of 'surge' if that helped - but don't think this this should be a > > 'due_to' any more since we are not pinning the changes in sea surface > > height to a specific process. In other words we would have something like: > > > > sea_surface_height_above_X = tidal_sea_surface_height_above_X + > > non_tidal_residual_of_sea_surface_height > > > > Cheers > > Andy > > > > > > -----Original Message----- > > From: CF-metadata [mailto:[email protected]] On Behalf > > Of Jonathan Gregory > > Sent: 03 May 2018 17:52 > > To: [email protected] > > Subject: [CF-metadata] proposed new standard name for storm surge > > residual > > > > 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 > > > > > > > >> _t > > > > > > > >> id > > > > > > > >> e< > > > > > > > >> ja > > > > > > > >> va > > > > > > > >> sc > > > > > > > >> r > > > > > > > >> ipt:void(0)> > > > > > > > >> > > > > > > > >> And the pole tide > > > > > > > >> sea_surface_height_amplitude_due_to_pole_tide<javascript: > > > > > > > >> vo > > > > > > > >> id > > > > > > > >> (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_win > > > > > > > >> d_ > > > > > > > >> at > > > > > > > >> _h > > > > > > > >> ig > > > > > > > >> h_ > > > > > > > >> fr > > > > > > > >> e > > > > > > > >> quency<javascript:void(0)> > > > > > > > >> sea_surface_height_correction_due_to_air_pressure_at_low_ > > > > > > > >> fr > > > > > > > >> eq > > > > > > > >> 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_surg > > > > > > > >> e > > > > > > > >> 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@met > > > > > > > >> of > > > > > > > >> fi > > > > > > > >> 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 > > _______________________________________________ > > 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
