Custom Query (124 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (37 - 39 of 124)

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Ticket Resolution Summary Owner Reporter
#7 wontfix Unstructured Grids SuperGrid Requirements cf-wg-supporting-technologies@… tomgross
Description

The irregular grid specifications have brought up several spatial objects which are not precisely described by a single coordinate location. For instance the edge of a triangle, or the triangle itself. An edge must be described by two points and the triangle by three points. A variable such as heat flux or area are not, necessarily, located at a single point. For convenience we could define spatial locations, center of edge or center of triangle, which could serve as coordinate locations for these variables. As it will still be necessary to describe the edge or triangle, by calling out the locations of the vertices, these derived locations are redundant. These extra locations are very much like the gridspec supergrid points (Balaji 2006). They might be useful enough to become a requirement of the CF conventions.

Should there be a requirement for the inclusion of these auxiliary locations for the center points of higher dimensional objects, such as line segments or areas?

#93 fixed Two new dimensionless vertical coordinate specifications for s coordinate ocean models cf-conventions@… rsignell
Description

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.

#88 fixed Terms of Reference for the CF Data Model davidhassell markh
Description

Objective

The purpose of this ticket is to agree the scope and terms of reference for the CF data model.

Proposal

Scope, Terms and Conditions

  1. The CF community will adopt a data model as part of the CF Metadata Project.
  2. The data model will be a complementary resource to the:
    • CF Conventions Document
    • CF Standard Name Table
    • CF Conformance Requirements & Recommendations
    • Guidelines for Construction of CF Standard Names
  3. The data model will be maintained by the community, using the same mechanisms as are used for the conventions, conformance and standard_name documents.
  4. The data model, once it has reached v1.0, will be consistent with the CF Conventions Document.
    • This consistency will be maintained.
      • Changes to the specification should be evaluated to determine whether they are consistent with the data model: if inconsistencies exist, these should be addressed, either by altering the specification change proposal or by proposing a change to the data model.
  5. The scope of the data model is to define the concepts of CF and the relationships that exist between these concepts.
  6. The data model provides a logical abstraction of the concepts defined by CF, independent of implementation details.
  7. The data model does not define the interface to CF.

Benefits

The data model is believed to offer the following benefits providing:

  • an orientation guide to the CF Conventions Document
  • a guide to the development of software compatible with CF
  • a reference point for gap analysis and conflict analysis of the CF specification
  • a communication tool for discussing CF concepts and proposals for changes to the CF specification
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Note: See TracQuery for help on using queries.