⇐ ⇒

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

From: Bert Jagers <Bert.Jagers>
Date: Sun, 1 Nov 2015 09:46:04 +0000

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.
Received on Sun Nov 01 2015 - 02:46:04 GMT

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

⇐ ⇒