Dear Jonathan,
Thank you for your comments.
* 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.
* 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.
> Perhaps it means solid_fraction_of_sediment_layer?
The overall solid_fraction would be equivalent to 1-soil_porosity and hence we don't store it.
> 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: "sediment_fraction_mass_per_unit_area" with either "_in_sediment_layer" added or cell measure sum over layer if layer thickness is coordinate.
> 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.
> Should these names also have sea_floor in them?
As indicated above, I would prefer to use sea_floor as little as possible. These names could be pretty generically.
> * soil_porosity
It's OK to reuse this if it's exactly what you mean, but if sediment is not soil, you could propose a new name.
> Your suggestion for formula_terms isn't what this attribute is intended for, I would say. Its aim is to indicate how parametric vertical coordinates are converted into dimensional geolocated ones. I understand your need, to compute the bottom of the layer from the layer thicknesses and the vertical coordinate of the sea floor, but I wonder whether a CF convention is required. Are there other similar use-cases which would make this a more general need?
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+Staggered+Grid+data+model+%28SGRID%29
Best regards,
Bert
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 09 November 2015 19:13
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] standard names and vertical coordinate for bed stratigraphy / sediment layers
Dear Bert
The new quantities you want to name deserve standard names, I agree.
> * 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?
> * 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%? Perhaps it means solid_fraction_of_sediment_layer? 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. Could "layer" be omitted from the volume_fraction? - it's an intensive quantity, not dependent on layer thickness. Should these names also have sea_floor in them?
> * soil_porosity
It's OK to reuse this if it's exactly what you mean, but if sediment is not soil, you could propose a new name.
Your suggestion for formula_terms isn't what this attribute is intended for, I would say. Its aim is to indicate how parametric vertical coordinates are converted into dimensional geolocated ones. I understand your need, to compute the bottom of the layer from the layer thicknesses and the vertical coordinate of the sea floor, but I wonder whether a CF convention is required. Are there other similar use-cases which would make this a more general need?
Best wishes
Jonathan
----- Forwarded message from Bert Jagers <Bert.Jagers at deltares.nl> -----
> Date: Sun, 1 Nov 2015 09:46:04 +0000
> From: Bert Jagers <Bert.Jagers at deltares.nl>
> To: CF Metadata Mail List <cf-metadata at cgd.ucar.edu>
> Subject: [CF-metadata] standard names and vertical coordinate for bed
> stratigraphy / sediment layers
>
> Dear all,
>
> We are trying to capture bed stratigraphy in a CF compliant NetCDF file. What do I mean by bed stratigraphy? Well, if you start digging in the ground you will come across sediment layers with different properties - that layering is referred to as bed stratigraphy. For biochemical models we may be interested in representing layers of just a few mm thick (to capture transitions been oxygen based chemistry to nitrate or sulfur based chemistry) while for coastal/estuarine/river morphodynamic studies the modeled layers would typically be 0-50 cm thick. On the other end of the spectrum we do studies to capture the long-term build-up of bed stratigraphy for future oil and gas reservoirs and then layers may be even thicker. See for instance the white-yellow-red-black colors representing the sand/clay ratio in this figure:
> https://www.deltares.nl/app/uploads/2015/09/Morphology-and-stratigraph
> y-in-a-numerical-analogue-735x389.png
>
> For the time being we can assume the number of layers fixed, but the thickness and properties of layers and vertical position of the layers varies over time due to processes such as erosion and deposition, consolidation, and bioturbation. With a significant number of layers included in the model and a fair number of output times to capture the processes responsible for the development of the bed stratigraphy, storage efficiency is important. For this reason I'm trying to avoid the classic CF route of storing a vertical position for each layer center plus for each layer the upper and lower bound which duplicates a lot of vertical information. Our proposal is to introduce a quantity with the following standard name:
>
> * thickness_of_sediment_layers_below_sea_floor
> This would typically be a NTIME x NCELLS x NLAYERS array (where NCELLS could be 1-dimensional for an unstructured grid or 2-dimensional, i.e. IMAX x JMAX, for a structured grid model) representing the the thickness of the NLAYERS sediment layers. By the way please note that the administration of layers is in general carried independently per computational cell, so layer k of cell j1 does not need to be connected to layer k of neighboring cell j2. We would also like to use this array as auxiliary vertical coordinate in a way similar to the dimensionless vertical coordinates. The addition "below_sea_floor" hints at this second purpose. We would like to reuse the formula_terms attribute of the dimensionless vertical coordinates here:
>
> float DZSED(NTIME, NCELLS, NLAYERS) ;
> DZSED:long_name = "thickness of modelled sediment layers" ;
> DZSED:standard_name = "thickness_of_sediment_layers_below_sea_floor" ;
> DZSED:formula_terms = "zref: BL thick: DZSED lyrdim: NLAYERS"
>
> where
> - zref would point to a variable "sea_floor_depth_below_geoid" or an altitude equivalent thereof since we can't differentiate between the altitude of the sea floor, the river bed, or the flood plains and the latter ones are commonly stored positive upward.
> - thick refers to the thickness variable itself.
> - lyrdim refers to the dimension associated with the layers; we need this since contrary to the dimensionless vertical coordinates this auxiliary vertical coordinate will typically have multiple dimensions.
>
> The vertical position of the top of layer k would then be computed as
>
> z(n,ji,k) = zref(n,ji) - sum(thick(n,ji,lyrdim), lyrdim = 1:k-1)
>
> and the bottom of the layer would be located at:
>
> z(n,ji,k) = zref(n,ji) - sum(thick(n,ji,lyrdim), lyrdim = 1:k)
>
> where n represents the typical time dimension and ji reprent one or two horizontal dimensions. Note that this formula assumes that lyrdim = 1 corresponds to the top layer. We don't specify a specific formula for the representative center of the layer; it's a location that we don't use.
>
> Associated with each layer we aim to store quantities such as:
>
> * mass_content_of_sediment_fraction_in_sediment_layer
> Typically a NTIME x NCELLS x NLAYERS x NFRAC array containing the mass per unit area per sediment fraction per layer per time step stored (unit kg/m2).
>
> and optionally:
>
> * volume_fraction_of_sediment_fraction_in_sediment_layer
> "Volume fraction" is used in the construction volume_fraction_of_X_in_Y, where X is a material constituent of Y. Typically a NTIME x NCELLS x NLAYERS x NFRAC array containing the volume fraction per sediment fraction per layer per time step stored (unit 1). The dimension representing the number of sediment fractions NFRAC may include multiple model dependent gravel, sand, silt, clay fractions, so we need to generalize beyond the scope of the currently existing standard names of volume_fraction_of_clay/sand/silt_in_soil.
>
> * soil_porosity
> The soil porosity is the proportion of its total volume not occupied by soil solids. This is an existing standard_name which most likely can be reused.
>
> The last two items link to already existing CF standard names based on the word "soil". Since we typically focus only on the physical processes of sediment transport, we usually refer to the layers as sediment_layers, but it might be okay to generalize the above to soil_layers.
>
> We are starting with the in-house implementation now, but the code will start to be spread more widely early next year. So, I'm looking forward to your feedback and hope to make good progress on the storage convention.
>
> Best regards,
>
> Bert
> 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 at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
CF-metadata at 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.
Received on Mon Nov 09 2015 - 14:02:20 GMT
