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_wind_ > > > > > > >> 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_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@metof > > > > > > >> 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
