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.jag...@deltares.nl> -----

> Date: Sun, 1 Nov 2015 09:46:04 +0000
> From: Bert Jagers <bert.jag...@deltares.nl>
> To: CF Metadata Mail List <cf-metadata@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@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to