Custom Query (124 matches)

1. Title

Two new dimensionless vertical coordinates to support ocean models

2. Moderator

Rich Signell

3. Requirement

The ocean modeling community needs two additional vertical coordinate specifications to allow modern s-coordinate model output to be CF-compliant and allow more general specification of s-coordinate model output for future development.

4. Initial Statement of Technical Proposal

The existing ocean_s_coordinate dimensionless vertical coordinate specification in CF is limited to a specific vertical stretching function and set of control parameters, while modern versions of ROMS allow for more flexible specification. Additional of these two new generalized vertical coordinate specifications would allow output from existing ROMS-derived models (and other s coordinate models) to be CF-compliant, as well as allowing more flexibility for future s_coordinate model developers and users to write and read CF-compliant model output.

Here are the proposed additions to Appendix D. Dimensionless Vertical Coordinates

Ocean s-coordinate, generic form 1

   standard_name = "ocean_s_coordinate_g1"

Definition:

   z(n,k,j,i) = S(k,j,i) + eta(n,j,i) * (1 + S(k,j,i) / depth(j,i))

    where S(k,j,i) = depth_c * s(k) + (depth(j,i) - depth_c) * C(k)

and where z(n,k,j,i) is the height, positive upwards, relative to ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i); eta(n,j,i) is the height of the ocean surface, positive upwards, relative to ocean datum at gridpoint (n,j,i); s(k) is the dimensionless coordinate at vertical gridpoint (k) with a range of -1 <= s(k) <= 0, s(0) corresponds to eta(n,j,i) whereas s(-1) corresponds to depth(j,i); C(k) is the dimensionless vertical coordinate stretching function at gridpoint (k) with a range of -1 <= C(k) <= 0, C(0) corresponds to eta(n,j,i) whereas C(-1) corresponds to depth(j,i); and the constant depth_c, (positive value), is a critical depth controlling the stretching.

The format for the formula_terms attribute is

formula_terms = "s: var1 C: var2 eta: var3 depth: var4 depth_c: var5"

Ocean s-coordinate, generic form 2

   standard_name = "ocean_s_coordinate_g2"

Definition:

   z(n,k,j,i) = eta(n,j,i) + (eta(n,j,i) + depth(j,i)) * S(k,j,i)

    where S(k,j,i) = (depth_c * s(k) + depth(j,i) * C(k)) / (depth_c + depth(j,i))

and where z(n,k,j,i) is the height, positive upwards, relative to ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i); eta(n,j,i) is the height of the ocean surface, positive upwards, relative to ocean datum at gridpoint (n,j,i); s(k) is the dimensionless coordinate at vertical gridpoint (k) with a range of -1 <= s(k) <= 0, s(0) corresponds to eta(n,j,i) whereas s(-1) corresponds to depth(j,i); C(k) is the dimensionless vertical coordinate stretching function at gridpoint (k) with a range of -1 <= C(k) <= 0, C(0) corresponds to eta(n,j,i) whereas C(-1) correspond to depth(j,i); and the constant depth_c, (positive value) is a critical depth controlling the stretching.

The format for the formula_terms attribute is

formula_terms = "s: var1 C: var2 eta: var3 depth: var4 depth_c: var5"

5. Benefits

The oceanographic community, especially those producing or consuming products from s coordinate models (e.g. variants and derivatives of the Regional Ocean Modeling System (ROMS)) would benefit from the addition of these two new dimensionless vertical coordinate specifications. These two new coordinates have been exercised in the Unidata Common Data Model and the Unidata NetCDF-Java Library for the last two years. It's time to add them officially to the CF Conventions.

6. Status Quo

The only option currently to store modern ROMS results as CF compliant would be to write the entire Z field as a 4D array.

Allow standard_name attribute to be comprised of a standard name optionally followed by one or more blanks and a standard name modifier (a string value from ​Appendix C, Standard Name Modifiers).

Section 3.5 of the conventions document states that "The flag_values attribute is the same type as the variable to which it is attached, and contains a list of the possible flag values."

E.g.

current_speed_qc:flag_values = 0b, 1b, 2b ;

But Appendix A specified the flag_values type as string. This is what the checker based the check on which is incorrect.

The conventions document has been corrected. The CF checker needs to implement this change too.