⇐ ⇒

[CF-metadata] standard names and vertical coordinate for bed stratigraphy / sediment layers

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 9 Nov 2015 18:12:30 +0000

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-stratigraphy-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 -----
Received on Mon Nov 09 2015 - 11:12:30 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒