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+Staggered+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
Received on Tue Nov 10 2015 - 07:49:48 GMT
