Follow-up of Nov 2015 thread: "standard names and vertical coordinate for bed stratigraphy / sediment layers" ----------------------------------------------------------------------------------------------------------------------------------------------------------
Dear Jonathan, Roy, Steve, all, I've finally again time to focus on this issue. The feedback that I got from Roy and Jonathan is to store the depth rather than trying to define a formula for computing the depth from layer thicknesses (and nobody suggested anything else). So, what I'll need is a name for the quantity that stores the (minimum/maximum/...) depths of the sedimentation layers. To summarize the comments made earlier: The discussion with Roy Lowry hinted at standard names for the vertical coordinate at: * depth_below_seabed, or * depth_below_sea_floor In the context of defining a standard name for the thickness of sediment layers, Jonathan asked whether the phrase "below_sea_floor" would be necessary in the initially suggested name "thickness_of_sediment_layers_below_sea_floor". I fully agree with Jonathan that it would much better to simply refer to "thickness_of_sediment_layers" without any addition since I'm actually interested in sediment layers that could be below land or water (rivers, lakes, estuaries, seas, ...). BTW. I'm indeed primarily interested in active sedimentation (and erosion) processes, such that this will usually exclude sedimentary rock (although the base layer of the alluvial sediment layers will typically be equal to the top of the sedimentary rock - if such a clear distinction can be made). So, can we come up with a name for the vertical coordinate without reference to "below_sea_floor"? The existing standard name "depth" refers to the vertical distance below the surface where I assume 'surface' should be read as "the lower boundary of the atmosphere" as in other quantities. That's not the surface I'm looking for. I would be looking for the surface consisting of the land surface and the river/lake/eastuary/sea/ocean floor. Would this be the earth_surface or would you interpret the earth_surface as equivalent to the "the lower boundary of the atmosphere". Another alternative could possibly be soil_surface. A more generic approach could be to define a standard_name "depth_below_reference_surface" (with unit m) which would then need a reference surface which in our case could be either the sea_floor_depth_below_geoid and/or the land surface. However, I don't see any previous case setting a convention for defining reference plane. There are two exiting examples of reference surfaces: (1) * geoid_height_above_reference_ellipsoid, * height_above_reference_ellipsoid, * histogram_of_backscattering_ratio_over_height_above_reference_ellipsoid, * histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid, and * sea_surface_height_above_reference_ellipsoid all refer to a reference_ellipsoid. However, there doesn't seem to be a way of defining the reference_ellipsoid (at least no reference is made to a description of how this ellipsoid should be defined), and furthermore the ellipsoid would be too generic for our application where we really need the local topography (or bathymetry) as reference surface. (2) * water_surface_height_above_reference_datum is defined relative to a reference surface with the explicit name: * water_surface_reference_datum_altitude which makes it impossible to reuse an already existing quantity (such as sea_floor_depth_below_geoid). Can we define a standard_name "depth_below_reference_surface" which would require an explicit attribute 'reference_surface' that points to any depth or altitude variable? Best regards, Bert -----Original Message----- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 10 November 2015 15:50 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] standard names and vertical coordinate for bed stratigraphy / sediment layers Dear Bert > * thickness_of_sediment_layers_below_sea_floor > > > Is below_sea_floor necessary in this name? If the aim is to indicate what > > sediment you mean, would thickness_of_sea_floor_sediment_layer be OK? > > We came up with the "below_sea_floor" phrase since we considered to use this > variable as a vertical coordinate as explained in the mail. Roy Lowry > suggested (in a partially offline discussion) to replace the thickness > variable with the proposed formula by an explicit neutral vertical coordinate > "depth_below_sea_floor" and subsequently specify both maximum and minimum > values per layer. This would be consistent with observation data but it would > no longer be clear that the layers are consecutive (or you would have to > check whether the minimum depth of one layer matches the maximum depth of the > other layer). On the other hand I would love to get rid of the > "below_sea_floor" addition since the layers could be in rivers, lakes, or > below dry land as well. I think it might be better to separate your two purposes of naming quantities and constructing coordinates. This quantity is one which could be used in other situations where it's not a coordinate, and below_sea_floor would then be confusing. Would just thickness_of_sediment_layer be OK? Can sediment mean anything else in geoscientific terminology? Below dry land, are you thinking of sedimentary rock? - that is different, I would say. Sediments are at the bottom of liquid, in my understanding (although I appreciate that sedimentary rock started like that). I note that due_to_sedimentation appears in the stdname table, and I think it's the same meaning of sedimentation. > > In using mass_content you are following other standard names, I know, but > > it might not be clear what it means, and I wonder if mass_per_unit_area > > might be better, which is also in use. > > Mass_per_unit_area sounds better to me as well OK. I agree that "areic" is not a well-known word (I hadn't heard it before) and since it is not used in CF already I'd rather not introduce it. I think "mass content" makes sense in the context of atmosphere_mass_content_of_X, where is it most often used, and it's also the sense in soil_moisture_content. > * mass_content_of_sediment_fraction_in_sediment_layer > * volume_fraction_of_sediment_fraction_in_sediment_layer > > > sediment_fraction_of_sediment_layer sounds odd to me. Isn't it 100%? > > Yes, the name did feel odd to me as well, but it isn't 100%. In the model we > can include any number of sediment fractions (think gravel, sand, silt, clay, > but the sediment classes can be subdivided further or grouped differently > dependent on the use case, so predefined enumeration is not an option). So, I > would explain the term as the mass_content or volume_fraction of a particular > sediment fraction (likely to be an array dimension to be associated with a > string valued scalar coordinate containing sediment fraction names and > auxiliary sediment fraction properties such as fraction specific minimum, > median, and maximum grain size, specific density, etc. I see. Just as there are many atmosphere_mass_content_of_X names, you could have several mass_per_unit_area_of_X_in_sediment_layer for various X. That would be clearer than using sediment in two senses. If you want to have a coordinate variable which runs over X, I agree that you need a generic name. Maybe it could be sediment_type, like area_type? > > Could "layer" be omitted from the volume_fraction? - it's an intensive > > quantity, not dependent on layer thickness. > Yes, probably it can. Was trying to make names similar. Yes, I understand, but it would be more generally useful without. > Our model is not the only model to use multiple sediment layers, so I do > think that it is not very specific to our own use case. However, there seems > as Roy indicated some discussion how to store it most generically. There are > a couple of options: > 1) would be to specify a regular CF coordinate for the centres of the N > layers and then upper and lower bounds of the N layers, but I consider this > to be too verbose (and also there is currently no CF bounds formulation that > would allow us to do precisely this): 3N values. > 2) define per layer the maximum and minimum depth: 2N values. This still > duplicates data, but seems to be consistent with observation data practices > of SeaDataNet. Also separate minimum and maximum values suggest that layers > may not be consecutive; there could be gaps; or layers may overlap. I'm > interested in just a simple stack of layers. > 3) define the N thicknesses of the layers and define how to determine the > vertical coordinate using some formula (this is what I tried). > 4) define the N+1 layer interfaces and use this as a coordinate for > the quantities in the N layers. The CF conventions don't have any > feature to support this. Following the UGRID development we worked a > bit in this direction with SGRID: > https://publicwiki.deltares.nl/display/NETCDF/Deltares+proposal+for+St > aggered+Grid+data+model+%28SGRID%29 I like (2) best, especially if it's been used before, because it's most like CF bounds and is more general. You could avoid defining standard names for the maximum and minimum depth if you had some notional vertical 1D coordinate variable (say VERTICAL). In that case the max and min depths could be auxiliary coord variables that were also data variables in their own right, distinguished by cell_methods that contain "VERTICAL: maximum" and "VERTICAL: minimum". Alternatively we could define some new CF bounds convention for this sort of case. CF presently does not have a convention which adds a single dimension of size 2 to a multidimensional bounds variable. The convention would have to indicate which spatial dimension the 2 applies to. E.g. you might have data variables (vertical,lat,lon) and a bounds variable (vertical,lat,lon,2) or upper and lower vertical bounds that depend on (vertical,lat,lon). I am sure that such a mechanism would be needed by other applications. In fact I recall some related discussion on email before. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
