From 3cf19451e6710416912a9b9ed257edc3d00cb1a2 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 17:30:28 +0000 Subject: [PATCH 01/53] Mesh Topology Variable --- images/cfdm_cf_concepts.gv | 8 +- images/cfdm_cf_concepts.svg | 295 +++++++++++++++++++----------------- 2 files changed, 165 insertions(+), 138 deletions(-) diff --git a/images/cfdm_cf_concepts.gv b/images/cfdm_cf_concepts.gv index a95e0633..9ec6afa0 100644 --- a/images/cfdm_cf_concepts.gv +++ b/images/cfdm_cf_concepts.gv @@ -3,7 +3,7 @@ # # cfdm_cf_concepts.svg created with: # -# $ dot -T svg cfdm_cf_concepts.gv cfdm_cf_concepts.svg +# $ dot -T svg cfdm_cf_concepts.gv -o cfdm_cf_concepts.svg # ==================================================================== digraph {splines=ortho nodesep="+0.25" @@ -51,6 +51,7 @@ CellMeasure [label="Cell\nMeasure\nVariable"] AncillaryData [label="Ancillary\nData\nVariable"] BoundaryVariable [label="Boundary\nVariable"] GridMapping [label="Grid\nMapping\nVariable"] +MeshTopology [label="Mesh\nTopology\nVariable"] # -------------------------------------------------------------------- # Invisible nodes used to aid in layout @@ -76,6 +77,7 @@ route11 route12 route13 route14 +route15 edge [arrowtail=none arrowhead=none @@ -117,8 +119,10 @@ route8 -> route9 [] route9 -> CellMeasure [weight=100] route9 -> route10 [] route10 -> AncillaryData [weight=100] +route10 -> route15 [] +route15 -> MeshTopology [weight=100] -{rank=same; route4, route5, route6, route7, route8, route9, route10} +{rank=same; route4, route5, route6, route7, route8, route9, route10, route15} {rank=same; GenericCoordinate, BoundaryVariable, Data, Domain, CellMeasure, AncillaryData GridMapping} GenericCoordinate -> BoundaryVariable [arrowhead=vee arrowtail=none minlen=2 headlabel="0..1 "] diff --git a/images/cfdm_cf_concepts.svg b/images/cfdm_cf_concepts.svg index 5c631d15..9cd567e4 100644 --- a/images/cfdm_cf_concepts.svg +++ b/images/cfdm_cf_concepts.svg @@ -1,373 +1,396 @@ - - + %3 - + NetCDFDimension - -NC::Dimension + +NC::Dimension NetCDFVariable - -NC::Variable + +NC::Variable NetCDFDimension->NetCDFVariable - - -    0..* + + +    0..* NetCDFAttribute - -NC::Attribute + +NC::Attribute NetCDFVariable->NetCDFAttribute - - - -0..*     + + + +0..*     - + route7 - + NetCDFVariable->route7 - - + + GenericCoordinate - -<<abstract>> -Generic -Coordinate -Variable + +<<abstract>> +Generic +Coordinate +Variable BoundaryVariable - -Boundary -Variable + +Boundary +Variable - + GenericCoordinate->BoundaryVariable - - -0..1     + + +0..1     - + route4 - + GenericCoordinate->route4 - + - + route12 - + - + GenericCoordinate->route12 - - + + Dimension - -Dimension + +Dimension - + route3 - + Dimension->route3 - + CellMethods - -Cell Methods + +Cell Methods - + route1 - + CellMethods->route1 - + - + route2 - + CellMethods->route2 - + - + route11 - + FormulaTerms - -Formula Terms + +Formula Terms FormulaTerms->NetCDFVariable - - -1..*   + + +1..*   FormulaTerms->route11 - + AuxiliaryCoordinate - -Auxiliary -Coordinate -Variable + +Auxiliary +Coordinate +Variable Coordinate - -Coordinate -Variable + +Coordinate +Variable ScalarCoordinate - -Scalar -Coordinate -Variable + +Scalar +Coordinate +Variable Data - -Data -Variable + +Data +Variable Domain - -Domain -Variable + +Domain +Variable CellMeasure - -Cell -Measure -Variable + +Cell +Measure +Variable AncillaryData - -Ancillary -Data -Variable + +Ancillary +Data +Variable GridMapping - -Grid -Mapping -Variable + +Grid +Mapping +Variable - + route8 - + GridMapping->route8 - + + + + +MeshTopology + +Mesh +Topology +Variable route1->NetCDFDimension - - -0..*    + + +0..*    route2->NetCDFAttribute - - + + route3->NetCDFDimension - - + + - + route5 - + route4->route5 - + route5->BoundaryVariable - + - + route6 - + route5->route6 - + route6->Data - + route6->route7 - + route7->Domain - + route7->route8 - + - + route9 - + route8->route9 - + route9->CellMeasure - + - + route10 - + route9->route10 - + route10->AncillaryData - + + + + +route15 + + + + +route10->route15 + route11->NetCDFAttribute - - + + - + route12->AuxiliaryCoordinate - + - + route13 - + - + route12->route13 - + - + route13->Coordinate - + - + route14 - + - + route13->route14 - + - + route14->ScalarCoordinate - + + + + +route15->MeshTopology + From c62e1d67f69db0f5f18081b912291d5969d65bff Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 17:30:44 +0000 Subject: [PATCH 02/53] Domain Topology Construct --- images/cfdm_field.gv | 38 +++-- images/cfdm_field.svg | 348 +++++++++++++++++++++++------------------- 2 files changed, 222 insertions(+), 164 deletions(-) diff --git a/images/cfdm_field.gv b/images/cfdm_field.gv index 0188ca2b..979a513e 100644 --- a/images/cfdm_field.gv +++ b/images/cfdm_field.gv @@ -3,7 +3,7 @@ # # cfdm_field.gv created with: # -# $ dot -T svg cfdm_field.gv cfdm_field.svg +# $ dot -T svg cfdm_field.gv -o cfdm_field.svg # ==================================================================== digraph {splines=ortho nodesep="+0.25" @@ -34,9 +34,12 @@ DataVariable [ # -------------------------------------------------------------------- Domain [ label="<>\nDomain" + width=2.5 + height=1 ] Field [ label="<>\nField" + height=1 ] CellMethod [ label="<>\nCellMethod" @@ -52,6 +55,7 @@ CellMeasure [ ] CoordinateReference [ label="<>\nCoordinateReference " + width=2.75 ] AuxiliaryCoordinate [ label="<>\nAuxillaryCoordinate" @@ -62,6 +66,9 @@ DimensionCoordinate [ FieldAncillary [ label="<>\nFieldAncillary" ] +DomainTopology [ + label="<>\nDomainTopology" + ] GenericCoordinate [ label="<>\nGeneric\nCoordinate\nConstruct" fillcolor=white @@ -86,6 +93,10 @@ route6 route7 route8 route9 +route10 +route11 +route12 +route13 DataVariable -> Field [dir=back arrowtail=vee weight=100] @@ -104,7 +115,8 @@ edge [arrowtail=vee labelfontsize=11.0 ] -Domain -> GenericCoordinate [taillabel="0..* " weight=100] +Domain -> route11 [arrowtail=diamond arrowhead=none weight=100] +route11 -> GenericCoordinate [arrowhead=vee arrowtail=none headlabel="0..* " weight=100] route2 -> CellMethod [arrowhead=vee arrowtail=none headlabel="0..* " weight=100] route1 -> FieldAncillary [arrowhead=vee arrowtail=none headlabel="0..* " @@ -119,21 +131,24 @@ route6 -> CoordinateReference [arrowtail=none arrowhead=vee headlabel="0..* "] Domain -> route7 [arrowtail=diamond arrowhead=none] route7-> CellMeasure [headlabel="0..* " arrowhead=vee arrowtail=none] Domain -> DomainAncillary [headlabel="0..* " arrowhead=vee arrowtail=diamond] -FieldAncillary -> Domain [label="uses \nparent " +FieldAncillary -> Domain [label="uses \nparent " arrowhead=vee arrowtail=none labelfontsize=11.0] -DomainVariable -> route9 [dir=back arrowtail=vee] -route9 -> Domain [arrowtail=none arrowhead=none] {rank=same; DomainVariable, DataVariable} -{rank=same; route9, FieldAncillary} + +route9 -> Domain [dir=none] +DomainVariable -> route9 [arrowtail=vee, arrowhead=none, weight=100] +{rank=same; route1, route9} +Domain -> DomainTopology [taillabel="0..* " weight=100] + GenericCoordinate -> route4 [arrowhead=none arrowtail=empty weight=100] -route4 -> AuxiliaryCoordinate [dir=none] +route4 -> AuxiliaryCoordinate [dir=none weight=100] {rank=same; route4, AuxiliaryCoordinate} -route4 -> route5 [dir=none] -route5 -> DimensionCoordinate [dir=none] +route4 -> route5 [dir=none weight=100] +route5 -> DimensionCoordinate [dir=none weight=100] {rank=same; route5, DimensionCoordinate} {rank=same;DomainAncillary, GenericCoordinate, route7, CellMeasure} @@ -155,7 +170,8 @@ route3 -> CoordinateReference [dir=none] # -------------------------------------------------------------------- DomainAxis -> AuxiliaryCoordinate [style=invis] DomainAxis -> CellMeasure [style=invis weight=100] -CellMeasure -> AuxiliaryCoordinate [style=invis] +CellMeasure -> AuxiliaryCoordinate [style=invis weight=100] AuxiliaryCoordinate -> DimensionCoordinate[style=invis weight=100] - +DomainVariable -> FieldAncillary [style=invis weight=100] +route9 -> route1 [style=invis weight=100] } diff --git a/images/cfdm_field.svg b/images/cfdm_field.svg index f4d430f8..2e658775 100644 --- a/images/cfdm_field.svg +++ b/images/cfdm_field.svg @@ -1,317 +1,359 @@ - - - + + %3 - + DomainVariable - -CN::Domain -Variable + +CN::Domain +Variable + + +FieldAncillary + +<<construct>> +FieldAncillary + + - + route9 - + - + DomainVariable->route9 - - + + DataVariable - -CN::Data -Variable + +CN::Data +Variable Field - -<<construct>> -Field + +<<construct>> +Field DataVariable->Field - - + + Domain - -<<construct>> -Domain + +<<construct>> +Domain DomainAxis - -<<construct>> -DomainAxis + +<<construct>> +DomainAxis - + Domain->DomainAxis - - - -0..*   + + + +0..*   DomainAncillary - -<<construct>> -DomainAncillary + +<<construct>> +DomainAncillary - + Domain->DomainAncillary - - - -0..*   + + + +0..*   - + -GenericCoordinate - -<<abstract>> -Generic -Coordinate -Construct +DomainTopology + +<<construct>> +DomainTopology - - -Domain->GenericCoordinate - - - -0..*    + + +Domain->DomainTopology + + + +0..*    - + route7 - + - + Domain->route7 - - + + + + + +route11 + + + + +Domain->route11 + + - + route2 - + Field->route2 - - + + - + route8 - + Field->route8 - - + + CellMethod - -<<construct>> -CellMethod + +<<construct>> +CellMethod - + CellMethod->DomainAxis - - - -1..*   + + + +1..*   CellMeasure - -<<construct>> -CellMeasure + +<<construct>> +CellMeasure AuxiliaryCoordinate - -<<construct>> -AuxillaryCoordinate + +<<construct>> +AuxillaryCoordinate CoordinateReference - -<<construct>> -CoordinateReference + +<<construct>> +CoordinateReference - + DomainAncillary->CoordinateReference - - -0..*       + + +0..*       DimensionCoordinate - -<<construct>> -DimensionCoordinate + +<<construct>> +DimensionCoordinate - - -FieldAncillary - -<<construct>> -FieldAncillary - - + FieldAncillary->Domain - - -uses       -parent         + + +uses              +parent                + + + +GenericCoordinate + +<<abstract>> +Generic +Coordinate +Construct - + route3 - + - + GenericCoordinate->route3 - - -0..*       + + +0..*       - + route4 - + - + GenericCoordinate->route4 - - + + - + route1 - + route1->Field - - + + - + route1->FieldAncillary - - -0..*   + + +0..*   - + route2->CellMethod - - -0..*    + + +0..*    - + route3->CoordinateReference - + - + route4->AuxiliaryCoordinate - + - + route5 - + - + route4->route5 - + - + route5->DimensionCoordinate - + - + route6 - + - + route6->Domain - - + + - + route6->CoordinateReference - - -0..*   + + +0..*   - + route7->CellMeasure - - -0..*   + + +0..*   route8->Domain - - -0..1   + + +0..1   route9->Domain - + + + + + +route10 + + + + +route11->GenericCoordinate + + +0..*    + + + +route12 + + + + +route13 + From 743c0848e65cb81c4cc5ebedbc41c4ca9a9a9417 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 17:31:13 +0000 Subject: [PATCH 03/53] Domain Topology Construct --- appi.adoc | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/appi.adoc b/appi.adoc index 3f56deca..c4d1b7ee 100644 --- a/appi.adoc +++ b/appi.adoc @@ -177,6 +177,9 @@ CF construct | Cell measure | Cell size or shape +| Domain topology +| Connectivity of domain cells + | Field ancillary | Ancillary metadata which varies within the domain @@ -282,6 +285,8 @@ construct) and relates the following metadata constructs * Cell measure constructs. +* Domain topology. + All of the constructs contained by the domain construct are optional (as indicated by "0.." in <>). @@ -596,6 +601,46 @@ domain which are not spanned by the array, along which the values are implicitly propagated. CF-netCDF cell measure variables correspond to cell measure constructs. +[[data-model-domain_topology]] +==== Domain topology construct + +A domain topology describes the connectivity of domain cells indexed +by a subset of the domain axis constructs. When two cells are +connected, operations on the data stored on them may be assumed to be +continuous across their common boundary. A domain topology construct +describes logically and explicitly the domain topology of cells +indexed by a single domain axis construct. + +A domain topology construct contains a connectivity array that spans a +single domain axis construct with the addition of an extra dimension +of the same size, such that each dimension indexes the cells. The +array is symmetrical, and each element indicates whether the pair of +cells to which its indices refer are connected. The connectivity of a +cell to itself is undefined, so the diagonal elements of this array +are ignored. A domain construct may contain at most one domain +topology construct. + +For any subset of the domain axis constructs, excluding a domain axis +construct for which there is a domain topology construct, there is an +implicit domain topology that is defined by a function of the physical +contiguousness of the cells, and/or the nature of the real world or +simulated processes that produced the data. For example, in a field +which contains both land and ocean cells, connections between land and +ocean cells might be excluded for some physical processes. The +description of such an implicit network topology may require metadata +that is external to CF. + +In CF-netCDF a domain topology can only be provided for a domain +defined by a UGRID mesh topology variable. In this case, the +connectivity array is supplied by a UGRID connectivity variable, such +as a "face_face_connectivity" variable. The information represented by +the symmetrical connectivity array of the domain topology construct in +the CF data model is stored in a different but equivalent way in +UGRID. The trailing dimension of a UGRID connectivity variable's data +records, for each cell, the indices of the other cells to which it is +connected (padded with missing data if a cell has fewer connections +than some others). + [[data-model-field-ancillary]] ==== Field ancillary constructs From a36e19d09309ea3f20e3c89f281545f55719e3f0 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 17:35:35 +0000 Subject: [PATCH 04/53] Domain Topology Construct --- appi.adoc | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/appi.adoc b/appi.adoc index c4d1b7ee..dcc4a24a 100644 --- a/appi.adoc +++ b/appi.adoc @@ -115,6 +115,9 @@ CF-netCDF element | Ancillary data variable | Metadata that depends on the domain +| Mesh topology variable +| Connectivity of domain cells + | Formula terms attribute | Vertical coordinate system @@ -285,7 +288,7 @@ construct) and relates the following metadata constructs * Cell measure constructs. -* Domain topology. +* Domain topology constructs. All of the constructs contained by the domain construct are optional (as indicated by "0.." in <>). @@ -608,8 +611,8 @@ A domain topology describes the connectivity of domain cells indexed by a subset of the domain axis constructs. When two cells are connected, operations on the data stored on them may be assumed to be continuous across their common boundary. A domain topology construct -describes logically and explicitly the domain topology of cells -indexed by a single domain axis construct. +(<>) describes logically and explicitly the +domain topology of cells indexed by a single domain axis construct. A domain topology construct contains a connectivity array that spans a single domain axis construct with the addition of an extra dimension From 475dd26ad3ec58b41f8b94ff4eb09d55d967ec3a Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 17:54:12 +0000 Subject: [PATCH 05/53] mesh, location, location_index_set --- appa.adoc | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/appa.adoc b/appa.adoc index 6495730a..85aa9df1 100644 --- a/appa.adoc +++ b/appa.adoc @@ -231,12 +231,30 @@ formula in the definition. | <> | Provides an example of a leap year for a user defined calendar. It is assumed that all years that differ from this year by a multiple of four are also leap years. +| **`location`** +| S +| D, Do +| <> and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ +| Specifies the (stagger) location within the mesh topology that at which the variable is defined. + +| **`location_index_set`** +| S +| D, Do +| <> and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ +| Identifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. + | **`long_name`** | S | C, D, Do | link:$$http://www.unidata.ucar.edu/software/netcdf/docs/attribute_conventions.html$$[NUG Appendix A, "Attribute Conventions"], and <> | A descriptive name that indicates a variable"s content. This name is not standardized. +| **`mesh`** +| S +| D, Do and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ +| <> +| Identifies a variable that defines a mesh topology. + | **`missing_value`** | D | C, D From 8aea5b053c0986851efe04fa1c10a1abd3420df8 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 19:46:02 +0000 Subject: [PATCH 06/53] appendix K first draft --- appk.adoc | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 192 insertions(+) create mode 100644 appk.adoc diff --git a/appk.adoc b/appk.adoc new file mode 100644 index 00000000..8c1472d1 --- /dev/null +++ b/appk.adoc @@ -0,0 +1,192 @@ + +[[appendix-mesh-topology, Appendix K, Mesh topology]] + +[appendix] +== Mesh topology + +link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ + +The "Type" values are **S** for string, and **I** for integer. The +"Use" values are **MT** for mesh topology variables, **LIS** location +index set variables, **D** for data variables, and **Do** for domain +variables + + +"Links" indicates the location of the +attribute"s original definition (first link) and sections where the +attribute is discussed in this document (additional links as +necessary). + +[[table-attributes]] +.Mesh topology attributes +[options="header",cols="6,2,2,8,12",caption="Table K.1. "] +|=============== +|{set:cellbgcolor!} +Attribute +| Type +| Use +| Links +| Description + +| **`topology_dimension`** +| I +| MT +| <> +| Indicates the highest dimensionality of the geometric elements. + +| **`cf_role`** +| S +| MT, LIS +| <> +| ?? + +| **`cf_role`** +| S +| MT, LIS +| <> +| ?? + +| **`node_coordinates`** +| S +| MT, LIS +| <> +| Specifies the auxiliary coordinate variables representing the node locations (latitude, longitude, or other spatial coordinates, and optional elevation or other coordinates). + +| **`edge_node_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every edge the indices of its begin and end nodes. + +| **`edge_coordinates`** +| S +| MT, LIS +| <> +| Identifies the auxiliary coordinate variables associated with the characteristic location of the edge (commonly the midpoint). + +| **`face_node_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every face the indices of its corner nodes. + +| **`face_dimension`** +| S +| MT, LIS +| <> +| Specifies the dimension used to indicate the index of the face in the connectivity arrays. + +| **`edge_dimension`** +| S +| C +| <> +| Identifies the dimension used to indicate the index of the edge in the connectivity arrays. + +| **`face_edge_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every face the indices of its edges. + +| **`face_face_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying all faces that share an edge with each face, i.e. are neighbours. + +| **`edge_face_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying all faces that share the same edge, i. e. are neighbours to an edge. + +| **`boundary_node_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every edge of each boundary the two nodes that it connects. (DCH - what is "the boundary") + +| **`face_coordinates`** +| S +| MT, LIS +| <> +| Specifies the auxiliary coordinate variables associated with the characteristic location of faces. + +| **`edge_coordinates`** +| S +| MT, LIS +| <> +| Specifies the auxiliary coordinate variables associated with the characteristic location of edges. + +| **`volume_node_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every volume the indices of its corner nodes. + +| **`volume_shape_type`** +| S +| MT, LIS +| <> +| Specifies a flag variable that specifies for every volume its shape. + +| **`volume_dimension`** +| I +| MT +| <> +| ?? + +| **`face_dimension`** +| I +| MT +| <> +| ?? + +| **`edge_dimension`** +| I +| MT +| <> +| ?? + +| **`volume_edge_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every volume the indices of its edges. + +| **`volume_face_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying for every volume the indices of its faces. + +| **`volume_volume_connectivity`** +| S +| MT, LIS +| <> +| Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. + +| **`volume_coordinates`** +| S +| MT, LIS +| <> +| Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. + +| **`location`** +| S +| D, Do +| <> and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ +| Specifies the (stagger) location within the mesh topology that at which the variable is defined. + +| **`location_index_set`** +| S +| D, Do +| <> +| Identifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. + +| **`mesh`** +| S +| LIS +| <> +| Identifies a variable that defines a mesh topology. +|=============== From 30219e3078b05bfcb45962b8880fbc2a4e7bdd25 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 19 Jan 2022 19:59:06 +0000 Subject: [PATCH 07/53] appendix K --- appk.adoc | 134 +++++++++++++++++++++--------------------------------- 1 file changed, 52 insertions(+), 82 deletions(-) diff --git a/appk.adoc b/appk.adoc index 8c1472d1..94a7c3d6 100644 --- a/appk.adoc +++ b/appk.adoc @@ -1,8 +1,8 @@ -[[appendix-mesh-topology, Appendix K, Mesh topology]] +[[appendix-mesh-topologies, Appendix K, Mesh topologies]] [appendix] -== Mesh topology +== Mesh topologies link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ @@ -12,11 +12,6 @@ index set variables, **D** for data variables, and **Do** for domain variables -"Links" indicates the location of the -attribute"s original definition (first link) and sections where the -attribute is discussed in this document (additional links as -necessary). - [[table-attributes]] .Mesh topology attributes [options="header",cols="6,2,2,8,12",caption="Table K.1. "] @@ -28,17 +23,11 @@ Attribute | Links | Description -| **`topology_dimension`** -| I -| MT -| <> -| Indicates the highest dimensionality of the geometric elements. - -| **`cf_role`** +| **`boundary_node_connectivity`** | S | MT, LIS -| <> -| ?? +| <> +| Specifies an index variable identifying for every edge of each boundary the two nodes that it connects. (DCH - what is "the boundary") | **`cf_role`** | S @@ -46,41 +35,41 @@ Attribute | <> | ?? -| **`node_coordinates`** +| **`edge_coordinates`** | S | MT, LIS | <> -| Specifies the auxiliary coordinate variables representing the node locations (latitude, longitude, or other spatial coordinates, and optional elevation or other coordinates). +| Identifies the auxiliary coordinate variables associated with the characteristic location of the edge (commonly the midpoint). -| **`edge_node_connectivity`** +| **`edge_dimension`** | S -| MT, LIS +| C | <> -| Specifies an index variable identifying for every edge the indices of its begin and end nodes. +| Identifies the dimension used to indicate the index of the edge in the connectivity arrays. -| **`edge_coordinates`** +| **`edge_face_connectivity`** | S | MT, LIS | <> -| Identifies the auxiliary coordinate variables associated with the characteristic location of the edge (commonly the midpoint). +| Specifies an index variable identifying all faces that share the same edge, i. e. are neighbours to an edge. -| **`face_node_connectivity`** +| **`edge_node_connectivity`** | S | MT, LIS | <> -| Specifies an index variable identifying for every face the indices of its corner nodes. +| Specifies an index variable identifying for every edge the indices of its begin and end nodes. -| **`face_dimension`** +| **`face_coordinates`** | S | MT, LIS | <> -| Specifies the dimension used to indicate the index of the face in the connectivity arrays. +| Specifies the auxiliary coordinate variables associated with the characteristic location of faces. -| **`edge_dimension`** -| S -| C -| <> -| Identifies the dimension used to indicate the index of the edge in the connectivity arrays. +| **`face_dimension`** +| I +| MT +| <> +| ?? | **`face_edge_connectivity`** | S @@ -94,99 +83,80 @@ Attribute | <> | Specifies an index variable identifying all faces that share an edge with each face, i.e. are neighbours. -| **`edge_face_connectivity`** +| **`face_node_connectivity`** | S | MT, LIS | <> -| Specifies an index variable identifying all faces that share the same edge, i. e. are neighbours to an edge. +| Specifies an index variable identifying for every face the indices of its corner nodes. -| **`boundary_node_connectivity`** +| **`location`** | S -| MT, LIS +| LIS, D, Do | <> -| Specifies an index variable identifying for every edge of each boundary the two nodes that it connects. (DCH - what is "the boundary") +| Specifies the (stagger) location within the mesh topology that at which the variable is defined. -| **`face_coordinates`** +| **`location_index_set`** | S -| MT, LIS -| <> -| Specifies the auxiliary coordinate variables associated with the characteristic location of faces. +| D, Do +| <> +| Identifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. -| **`edge_coordinates`** +| **`mesh`** | S -| MT, LIS +| LIS | <> -| Specifies the auxiliary coordinate variables associated with the characteristic location of edges. - -| **`volume_node_connectivity`** +| Identifies a variable that defines a mesh topology. +| **`volume_edge_connectivity`** | S | MT, LIS | <> -| Specifies an index variable identifying for every volume the indices of its corner nodes. +| Specifies an index variable identifying for every volume the indices of its edges. -| **`volume_shape_type`** +| **`node_coordinates`** | S | MT, LIS | <> -| Specifies a flag variable that specifies for every volume its shape. +| Specifies the auxiliary coordinate variables representing the node locations (latitude, longitude, or other spatial coordinates, and optional elevation or other coordinates). -| **`volume_dimension`** +| **`topology_dimension`** | I | MT | <> -| ?? +| Indicates the highest dimensionality of the geometric elements. -| **`face_dimension`** -| I -| MT -| <> -| ?? +| **`volume_coordinates`** +| S +| MT, LIS +| <> +| Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. -| **`edge_dimension`** +| **`volume_dimension`** | I | MT | <> | ?? -| **`volume_edge_connectivity`** -| S -| MT, LIS -| <> -| Specifies an index variable identifying for every volume the indices of its edges. - | **`volume_face_connectivity`** | S | MT, LIS | <> | Specifies an index variable identifying for every volume the indices of its faces. -| **`volume_volume_connectivity`** +| **`volume_node_connectivity`** | S | MT, LIS | <> -| Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. +| Specifies an index variable identifying for every volume the indices of its corner nodes. -| **`volume_coordinates`** +| **`volume_shape_type`** | S | MT, LIS | <> -| Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. - -| **`location`** -| S -| D, Do -| <> and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ -| Specifies the (stagger) location within the mesh topology that at which the variable is defined. - -| **`location_index_set`** -| S -| D, Do -| <> -| Identifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. +| Specifies a flag variable that specifies for every volume its shape. -| **`mesh`** +| **`volume_volume_connectivity`** | S -| LIS +| MT, LIS | <> -| Identifies a variable that defines a mesh topology. +| Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. |=============== From 8528e69b68e3e2bdf998da40cd080608c332c931 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 08:40:56 +0000 Subject: [PATCH 08/53] appk format --- appa.adoc | 16 ++++++++-------- appk.adoc | 53 ++++++++++++++--------------------------------------- 2 files changed, 22 insertions(+), 47 deletions(-) diff --git a/appa.adoc b/appa.adoc index 85aa9df1..d9a46010 100644 --- a/appa.adoc +++ b/appa.adoc @@ -79,7 +79,7 @@ Attribute | **`cf_role`** | S -| C +| C, - | <> | Identifies the roles of variables that identify features in discrete sampling geometries @@ -234,26 +234,26 @@ formula in the definition. | **`location`** | S | D, Do -| <> and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ +| link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] and <> | Specifies the (stagger) location within the mesh topology that at which the variable is defined. | **`location_index_set`** | S | D, Do -| <> and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ -| Identifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. +| link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] and <> +| Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`long_name`** | S | C, D, Do | link:$$http://www.unidata.ucar.edu/software/netcdf/docs/attribute_conventions.html$$[NUG Appendix A, "Attribute Conventions"], and <> -| A descriptive name that indicates a variable"s content. This name is not standardized. +| A descriptive name that indicates a variable's content. This name is not standardized. | **`mesh`** | S -| D, Do and link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ -| <> -| Identifies a variable that defines a mesh topology. +| D, Do +| link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] and <> +| Specifies a variable that defines a mesh topology. | **`missing_value`** | D diff --git a/appk.adoc b/appk.adoc index 94a7c3d6..c64f2dee 100644 --- a/appk.adoc +++ b/appk.adoc @@ -4,159 +4,134 @@ [appendix] == Mesh topologies -link:$$https://ugrid-conventions.github.io/ugrid-conventions$$ +link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] -The "Type" values are **S** for string, and **I** for integer. The -"Use" values are **MT** for mesh topology variables, **LIS** location -index set variables, **D** for data variables, and **Do** for domain -variables +The "Type" values are **S** for string, and **I** for integer. +The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables [[table-attributes]] .Mesh topology attributes -[options="header",cols="6,2,2,8,12",caption="Table K.1. "] +[options="header",cols="6,2,4,12",caption="Table K.1. "] |=============== |{set:cellbgcolor!} Attribute | Type | Use -| Links | Description | **`boundary_node_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying for every edge of each boundary the two nodes that it connects. (DCH - what is "the boundary") | **`cf_role`** | S | MT, LIS -| <> | ?? | **`edge_coordinates`** | S | MT, LIS -| <> | Identifies the auxiliary coordinate variables associated with the characteristic location of the edge (commonly the midpoint). | **`edge_dimension`** -| S -| C -| <> +| I +| MT, LIS | Identifies the dimension used to indicate the index of the edge in the connectivity arrays. | **`edge_face_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying all faces that share the same edge, i. e. are neighbours to an edge. | **`edge_node_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying for every edge the indices of its begin and end nodes. | **`face_coordinates`** | S | MT, LIS -| <> | Specifies the auxiliary coordinate variables associated with the characteristic location of faces. | **`face_dimension`** | I | MT -| <> | ?? | **`face_edge_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying for every face the indices of its edges. | **`face_face_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying all faces that share an edge with each face, i.e. are neighbours. | **`face_node_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying for every face the indices of its corner nodes. | **`location`** | S | LIS, D, Do -| <> | Specifies the (stagger) location within the mesh topology that at which the variable is defined. | **`location_index_set`** | S | D, Do -| <> -| Identifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. +| Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined, e.g. only at boundary points or at special locations like weirs and gates. | **`mesh`** | S -| LIS -| <> -| Identifies a variable that defines a mesh topology. -| **`volume_edge_connectivity`** -| S -| MT, LIS -| <> -| Specifies an index variable identifying for every volume the indices of its edges. +| LIS, D, Do +| Specifies a variable that defines a mesh topology. | **`node_coordinates`** | S | MT, LIS -| <> | Specifies the auxiliary coordinate variables representing the node locations (latitude, longitude, or other spatial coordinates, and optional elevation or other coordinates). +| **`volume_edge_connectivity`** +| S +| MT, LIS +| Specifies an index variable identifying for every volume the indices of its edges. + | **`topology_dimension`** | I | MT -| <> | Indicates the highest dimensionality of the geometric elements. | **`volume_coordinates`** | S | MT, LIS -| <> | Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. | **`volume_dimension`** | I | MT -| <> | ?? | **`volume_face_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying for every volume the indices of its faces. | **`volume_node_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying for every volume the indices of its corner nodes. | **`volume_shape_type`** | S | MT, LIS -| <> | Specifies a flag variable that specifies for every volume its shape. | **`volume_volume_connectivity`** | S | MT, LIS -| <> | Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. |=============== From f7c7ab8b6982bd2ad031aea125de3e8b8fcb5e4c Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 08:41:27 +0000 Subject: [PATCH 09/53] appk format --- appk.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appk.adoc b/appk.adoc index c64f2dee..c757ecbb 100644 --- a/appk.adoc +++ b/appk.adoc @@ -12,7 +12,7 @@ The "Use" values are **MT** for mesh topology variables, **LIS** for location in [[table-attributes]] .Mesh topology attributes -[options="header",cols="6,2,4,12",caption="Table K.1. "] +[options="header",cols="6,2,6,12",caption="Table K.1. "] |=============== |{set:cellbgcolor!} Attribute From 3976fb4168005c7782c457e877f568005efa9c3d Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 08:42:09 +0000 Subject: [PATCH 10/53] appk format --- appk.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appk.adoc b/appk.adoc index c757ecbb..601e6104 100644 --- a/appk.adoc +++ b/appk.adoc @@ -12,7 +12,7 @@ The "Use" values are **MT** for mesh topology variables, **LIS** for location in [[table-attributes]] .Mesh topology attributes -[options="header",cols="6,2,6,12",caption="Table K.1. "] +[options="header",cols="6,2,8,12",caption="Table K.1. "] |=============== |{set:cellbgcolor!} Attribute From c5ccd360f25addba771738d715fcb3a1c7317405 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 08:43:35 +0000 Subject: [PATCH 11/53] ref to appendix K --- appa.adoc | 4 ++-- appk.adoc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/appa.adoc b/appa.adoc index d9a46010..486cd089 100644 --- a/appa.adoc +++ b/appa.adoc @@ -5,8 +5,8 @@ == Attributes All CF attributes are listed here except for those that are used to -describe grid mappings. See Appendix F for the grid mapping -attributes. +describe grid mappings and mesh topologies. See Appendix F for the +grid mapping attributes, and Appendix K for mesh topology attributes. The "Type" values are **S** for string, **N** for numeric, and **D** for the type of the data variable. The "Use" values are **G** for diff --git a/appk.adoc b/appk.adoc index 601e6104..c64f2dee 100644 --- a/appk.adoc +++ b/appk.adoc @@ -12,7 +12,7 @@ The "Use" values are **MT** for mesh topology variables, **LIS** for location in [[table-attributes]] .Mesh topology attributes -[options="header",cols="6,2,8,12",caption="Table K.1. "] +[options="header",cols="6,2,4,12",caption="Table K.1. "] |=============== |{set:cellbgcolor!} Attribute From 069ce4ef6876ce72b4c55b8d8f9630504540a757 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 08:50:05 +0000 Subject: [PATCH 12/53] UGRID ref --- bibliography.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/bibliography.adoc b/bibliography.adoc index 98eed07b..b6689dc9 100644 --- a/bibliography.adoc +++ b/bibliography.adoc @@ -30,3 +30,4 @@ - [[[W3C]]] link:$$http://www.w3.org/$$[World Wide Web Consortium (W3C)] . - [[[XML]]] link:$$http://www.w3.org/TR/1998/REC-xml-19980210$$[ Extensible Markup Language (XML) 1.0 ] . T. Bray, J. Paoli, and C.M. Sperberg-McQueen. 10 February 1998 . - [[[CFDM]]] link:$$http://doi.org/10.5194/gmd-10-4619-2017$$[ A data model of the Climate and Forecast metadata conventions (CF-1.6) with a software implementation (cf-python v2.1) ] . Hassell, D., Gregory, J., Blower, J., Lawrence, B. N., and Taylor, K. E.: Geosci. Model Dev., 10, 4619-4646, https://doi.org/10.5194/gmd-10-4619-2017, 2017. +- [[[UGRID]]] link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID Conventions for storing unstructured (or flexible mesh) data in the netCDF file] From fb030c658c72a6b8b0e98da2fb0f20367ed27bf3 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 09:49:10 +0000 Subject: [PATCH 13/53] app K text --- appa.adoc | 6 ++-- appk.adoc | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 95 insertions(+), 7 deletions(-) diff --git a/appa.adoc b/appa.adoc index 486cd089..ccacb0c7 100644 --- a/appa.adoc +++ b/appa.adoc @@ -234,13 +234,13 @@ formula in the definition. | **`location`** | S | D, Do -| link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] and <> +| <> and <> | Specifies the (stagger) location within the mesh topology that at which the variable is defined. | **`location_index_set`** | S | D, Do -| link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] and <> +| <> and <> | Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`long_name`** @@ -252,7 +252,7 @@ formula in the definition. | **`mesh`** | S | D, Do -| link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] and <> +| <> and <> | Specifies a variable that defines a mesh topology. | **`missing_value`** diff --git a/appk.adoc b/appk.adoc index c64f2dee..94f62411 100644 --- a/appk.adoc +++ b/appk.adoc @@ -4,13 +4,26 @@ [appendix] == Mesh topologies -link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID conventions] +A mesh topology is the interconnection of various geometrical elements +of a domain on which data is defined. A __mesh topology variable__ +defines one or more domains, each of which has its own mesh topology, +and the topological connections between the domains are also +defined. For instance, <> +shows a mesh topology variable that defines a 2D triangular mesh +topology comprising three domains: one at the triangular element +nodes, one along the triangular element edges, and one on the +triangular faces. The nodes that define each edge, and the edges that +define each triangular face are also identified. + +A __location index set__ variable defines a subset of locations of another mesh topology, e.g. only boundary points or special locations like weirs and gates. +It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable. + +The canonical definitions of mesh topology and location index set variables are described in the UGRID conventions <>, but the standardized attributes are listed here for convenience. The "Type" values are **S** for string, and **I** for integer. The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables - -[[table-attributes]] +[[table-mesh-topology-attributes]] .Mesh topology attributes [options="header",cols="6,2,4,12",caption="Table K.1. "] |=============== @@ -83,7 +96,7 @@ Attribute | **`location_index_set`** | S | D, Do -| Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined, e.g. only at boundary points or at special locations like weirs and gates. +| Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`mesh`** | S @@ -135,3 +148,78 @@ Attribute | MT, LIS | Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. |=============== + + +[[cdl-mesh-topology-variable]] +[caption=""] +.Example K.1 A 2D triangular mesh topology variable. +==== +---- +dimensions: + nMesh2_node = 4 ; // nNodes + nMesh2_edge = 5 ; // nEdges + nMesh2_face = 2 ; // nFaces + +variables: + // Mesh topology variable + integer Mesh2 ; + Mesh2:cf_role = "mesh_topology" ; + Mesh2:long_name = "Topology data of 2D unstructured mesh" ; + Mesh2:topology_dimension = 2 ; + Mesh2:node_coordinates = "Mesh2_node_x Mesh2_node_y" ; + Mesh2:face_node_connectivity = "Mesh2_face_nodes" ; + Mesh2:face_dimension = "nMesh2_face" ; + Mesh2:edge_node_connectivity = "Mesh2_edge_nodes" ; + Mesh2:edge_dimension = "nMesh2_edge" ; + Mesh2:edge_coordinates = "Mesh2_edge_x Mesh2_edge_y" ; + Mesh2:face_coordinates = "Mesh2_face_x Mesh2_face_y" ; + Mesh2:face_edge_connectivity = "Mesh2_face_edges" ; + Mesh2:face_face_connectivity = "Mesh2_face_links" ; + Mesh2:edge_face_connectivity = "Mesh2_edge_face_links" ; + + // Connectivity variables + integer Mesh2_face_nodes(nMesh2_face, Three) ; + Mesh2_face_nodes:long_name = "Maps every triangular face to its three corner nodes." ; + integer Mesh2_edge_nodes(nMesh2_edge, Two) ; + Mesh2_edge_nodes:cf_role = "edge_node_connectivity" ; + Mesh2_edge_nodes:long_name = "Maps every edge to the two nodes that it connects." ; + integer Mesh2_face_edges(nMesh2_face, Three) ; + Mesh2_face_edges:cf_role = "face_edge_connectivity" ; + Mesh2_face_edges:long_name = "Maps every triangular face to its three edges." ; + integer Mesh2_face_links(nMesh2_face, Three) ; + Mesh2_face_links:cf_role = "face_face_connectivity" ; + Mesh2_face_links:long_name = "neighbor faces for faces" ; + Mesh2_face_links:_FillValue = -999 ; + Mesh2_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; + integer Mesh2_edge_face_links(nMesh2_edge, Two) ; + Mesh2_edge_face_links:cf_role = "edge_face_connectivity" ; + Mesh2_edge_face_links:long_name = "neighbor faces for edges" ; + Mesh2_edge_face_links:_FillValue = -999 ; + Mesh2_edge_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; + + // Data at faces, edges, and nodes + double volume_at_faces(nMesh2_face) ; + volume_at_faces:long_name = "volumes" ; + volume_at_faces:units = "m3" ; + volume_at_faces:mesh = "Mesh2" ; + volume_at_faces:location = "face" ; + volume_at_faces:coordinates = "Mesh2_face_x Mesh2_face_y" ; + double flux_at_edges(nMesh2_edge) ; + fluxe_at_edges:long_name = "flux across edge" ; + fluxe_at_edges:units = "m3 s-1" ; + fluxe_at_edges:mesh = "Mesh2" + fluxe_at_edges:location = "edge" ; + fluxe_at_edges:coordinates = "Mesh2_edge_x Mesh2_edge_y" ; + double volume_at_nodes(nMesh2_node) ; + volume_at_facess:long_name = "volumes" ; + volume_at_facess:units = "m3" ; + volume_at_facess:mesh = "Mesh2" ; + volume_at_facess:location = "node" ; + volume_at_facess:coordinates = "Mesh2_node_x Mesh2_node_y" ; +---- + +A mesh topology variable that defines a 2D triangular mesh topology comprising three domains: one at the triangular element nodes, one along the triangular element edges, and one on the triangular faces. +Each data variable selects exactly one of these for its domain. +The auxiliary coordinate variables identified by the **`node_coordinates`**, **`edge_coordinates`**, and **`face_coordinates`** mesh topology variable attributes have been omitted from the CDL for clarity. + +==== From 11cb475c2b346de82dae63ac0a36c33feb75ed0e Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 10:00:46 +0000 Subject: [PATCH 14/53] app K text --- appk.adoc | 45 +++++++++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/appk.adoc b/appk.adoc index 94f62411..6bf2c331 100644 --- a/appk.adoc +++ b/appk.adoc @@ -18,7 +18,7 @@ define each triangular face are also identified. A __location index set__ variable defines a subset of locations of another mesh topology, e.g. only boundary points or special locations like weirs and gates. It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable. -The canonical definitions of mesh topology and location index set variables are described in the UGRID conventions <>, but the standardized attributes are listed here for convenience. +The canonical definitions of mesh topology and location index set variables are given by the UGRID conventions <>, but the standardized attributes are listed here for convenience. The "Type" values are **S** for string, and **I** for integer. The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables @@ -35,7 +35,7 @@ Attribute | **`boundary_node_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying for every edge of each boundary the two nodes that it connects. (DCH - what is "the boundary") | **`cf_role`** @@ -45,27 +45,27 @@ Attribute | **`edge_coordinates`** | S -| MT, LIS +| MT | Identifies the auxiliary coordinate variables associated with the characteristic location of the edge (commonly the midpoint). | **`edge_dimension`** | I -| MT, LIS +| MT | Identifies the dimension used to indicate the index of the edge in the connectivity arrays. | **`edge_face_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying all faces that share the same edge, i. e. are neighbours to an edge. | **`edge_node_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying for every edge the indices of its begin and end nodes. | **`face_coordinates`** | S -| MT, LIS +| MT | Specifies the auxiliary coordinate variables associated with the characteristic location of faces. | **`face_dimension`** @@ -75,17 +75,17 @@ Attribute | **`face_edge_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying for every face the indices of its edges. | **`face_face_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying all faces that share an edge with each face, i.e. are neighbours. | **`face_node_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying for every face the indices of its corner nodes. | **`location`** @@ -105,13 +105,13 @@ Attribute | **`node_coordinates`** | S -| MT, LIS +| MT | Specifies the auxiliary coordinate variables representing the node locations (latitude, longitude, or other spatial coordinates, and optional elevation or other coordinates). -| **`volume_edge_connectivity`** -| S -| MT, LIS -| Specifies an index variable identifying for every volume the indices of its edges. +| **`start_index`** +| I +| MT +| Indicates whether 0- or 1-based indexing is used to identify connect geometric elements; connectivity indices are 0-based by default. | **`topology_dimension`** | I @@ -120,7 +120,7 @@ Attribute | **`volume_coordinates`** | S -| MT, LIS +| MT | Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. | **`volume_dimension`** @@ -128,24 +128,29 @@ Attribute | MT | ?? +| **`volume_edge_connectivity`** +| S +| MT +| Specifies an index variable identifying for every volume the indices of its edges. + | **`volume_face_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying for every volume the indices of its faces. | **`volume_node_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying for every volume the indices of its corner nodes. | **`volume_shape_type`** | S -| MT, LIS +| MT | Specifies a flag variable that specifies for every volume its shape. | **`volume_volume_connectivity`** | S -| MT, LIS +| MT | Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. |=============== From a5674f88d95be0175924210293cb81449195b3ea Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 10:05:55 +0000 Subject: [PATCH 15/53] app K text --- appk.adoc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/appk.adoc b/appk.adoc index 6bf2c331..130e8825 100644 --- a/appk.adoc +++ b/appk.adoc @@ -18,7 +18,7 @@ define each triangular face are also identified. A __location index set__ variable defines a subset of locations of another mesh topology, e.g. only boundary points or special locations like weirs and gates. It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable. -The canonical definitions of mesh topology and location index set variables are given by the UGRID conventions <>, but the standardized attributes are listed here for convenience. +The canonical definitions of mesh topology and location index set variables are given by the UGRID conventions <>, but the standardized attributes, many of which are optional, are listed here for convenience. The "Type" values are **S** for string, and **I** for integer. The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables @@ -43,6 +43,11 @@ Attribute | MT, LIS | ?? +| **`coordinates`** +| S +| LIS +| Identifies the auxiliary coordinate variables associated with the characteristic location of the subset of mesh topology locations. + | **`edge_coordinates`** | S | MT From 7562aefcb88ff783f64e04ad3e2b90c51e087881 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:30:17 +0000 Subject: [PATCH 16/53] section 5.9 --- ch05.adoc | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 129 insertions(+), 1 deletion(-) diff --git a/ch05.adoc b/ch05.adoc index 39f2b93c..8a4c03af 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1018,7 +1018,6 @@ variable **`domain`**. .A domain containing a timeseries of station data in the indexed ragged array representation. ==== ---- - dimensions: station = 23 ; obs = UNLIMITED ; @@ -1066,3 +1065,132 @@ the <> example have been replaced by the domain variable **`domain`**. ==== + + +[[mesh-topology-variables, Section 5.9, "Mesh Topology Variables"]] +=== Mesh Topology Variables + +A mesh topology is the interconnection of various geometrical elements +of a domain on which data is defined. A __mesh topology variable__ +defines one or more domains, each of which has its own mesh topology, +and the topological connections between the domains are also defined. +A data variable may use one of a mesh topology variable's domains by +identifying the mesh topology variable alongside the required +constituent domain, typically specified as being the domain defined by +one of the nodes, edges, face or volumes of the mesh topology (see +example <>). + +A __location index set__ variable defines a subset of locations of a +mesh topology variable, e.g. only boundary points or special locations +like weirs and gates. It is provided as a space saving device to +prevent the need to redefine parts of an existing mesh topology +variable, and as such is logically equivalent to a mesh topology +variable (see example <>). + +The canonical definitions of mesh topology and location index set +variables are given by the UGRID conventions <>, but the +standardized attributes, many of which are optional, are listed in +<> and <>. + +[[example-mesh-topology-variabley]] +[caption="Example 5.21. "] +.Triangular mesh topology variable. +==== +---- +dimensions: + nMesh2_node = 4 ; // nNodes + nMesh2_edge = 5 ; // nEdges + nMesh2_face = 2 ; // nFaces + +variables: + // Mesh topology variable + integer Mesh2 ; + Mesh2:cf_role = "mesh_topology" ; + Mesh2:long_name = "Topology data of 2D unstructured mesh" ; + Mesh2:topology_dimension = 2 ; + Mesh2:node_coordinates = "Mesh2_node_x Mesh2_node_y" ; + Mesh2:face_node_connectivity = "Mesh2_face_nodes" ; + Mesh2:face_dimension = "nMesh2_face" ; + Mesh2:edge_node_connectivity = "Mesh2_edge_nodes" ; + Mesh2:edge_dimension = "nMesh2_edge" ; + Mesh2:edge_coordinates = "Mesh2_edge_x Mesh2_edge_y" ; + Mesh2:face_coordinates = "Mesh2_face_x Mesh2_face_y" ; + Mesh2:face_edge_connectivity = "Mesh2_face_edges" ; + Mesh2:face_face_connectivity = "Mesh2_face_links" ; + Mesh2:edge_face_connectivity = "Mesh2_edge_face_links" ; + + // Connectivity variables + integer Mesh2_face_nodes(nMesh2_face, Three) ; + Mesh2_face_nodes:long_name = "Maps every triangular face to its three corner nodes." ; + integer Mesh2_edge_nodes(nMesh2_edge, Two) ; + Mesh2_edge_nodes:cf_role = "edge_node_connectivity" ; + Mesh2_edge_nodes:long_name = "Maps every edge to the two nodes that it connects." ; + integer Mesh2_face_edges(nMesh2_face, Three) ; + Mesh2_face_edges:cf_role = "face_edge_connectivity" ; + Mesh2_face_edges:long_name = "Maps every triangular face to its three edges." ; + integer Mesh2_face_links(nMesh2_face, Three) ; + Mesh2_face_links:cf_role = "face_face_connectivity" ; + Mesh2_face_links:long_name = "neighbor faces for faces" ; + Mesh2_face_links:_FillValue = -999 ; + Mesh2_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; + integer Mesh2_edge_face_links(nMesh2_edge, Two) ; + Mesh2_edge_face_links:cf_role = "edge_face_connectivity" ; + Mesh2_edge_face_links:long_name = "neighbor faces for edges" ; + Mesh2_edge_face_links:_FillValue = -999 ; + Mesh2_edge_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; + + // Data at faces, edges, and nodes + double volume_at_faces(nMesh2_face) ; + volume_at_faces:long_name = "volumes" ; + volume_at_faces:units = "m3" ; + volume_at_faces:mesh = "Mesh2" ; + volume_at_faces:location = "face" ; + volume_at_faces:coordinates = "Mesh2_face_x Mesh2_face_y" ; + double flux_at_edges(nMesh2_edge) ; + fluxe_at_edges:long_name = "flux across edge" ; + fluxe_at_edges:units = "m3 s-1" ; + fluxe_at_edges:mesh = "Mesh2" + fluxe_at_edges:location = "edge" ; + fluxe_at_edges:coordinates = "Mesh2_edge_x Mesh2_edge_y" ; + double height_at_nodes(nMesh2_node) ; + volume_at_faces:standard_name = "sea_surface_height_above_geoid" ; + volume_at_faces:units = "m" ; + volume_at_faces:mesh = "Mesh2" ; + volume_at_faces:location = "node" ; + volume_at_faces:coordinates = "Mesh2_node_x Mesh2_node_y" ; + +---- + +A mesh topology variable that defines a 2D triangular mesh topology comprising three domains: one at the triangular element nodes, one along the triangular element edges, and one on the triangular faces. +Each data variable selects exactly one of these for its domain. +The auxiliary coordinate variables identified by the **`node_coordinates`**, **`edge_coordinates`**, and **`face_coordinates`** mesh topology variable attributes have been omitted from the CDL for clarity. + +==== + +[[example-location-index-set-variable]] +[caption="Example 5.22. "] +.Location index set variable +==== +---- +dimensions: + time = 12 ; + nMesh2_set = 2 ; + +variables: + // Location index set variable + integer Mesh2_set(nMesh2_set) ; + Mesh2_set:cf_role = "location_index_set" ; + Mesh2_set:long_name = "Defines Mesh2_set as subset of the nodes of Mesh2."; + Mesh2_set:mesh = "Mesh2" ; + Mesh2_set:location = "node" ; + + // Data at a subset of the nodes of Mesh2 + double Mesh2_waterlevel(time, nMesh2_set) ; + Mesh2_waterlevel:standard_name = "sea_surface_height_above_geoid" ; + Mesh2_waterlevel:units = "m" ; + Mesh2_waterlevel:location_index_set = "Mesh2_set" ; +---- + +The mesh topology variable `Mesh2`, defined in example <>, has four nodes, two of which are used here to define the new domain in `Mesh2_set`. + +==== From 6ccf39d7ac2631788c4b431064d4beeb0925a6f0 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:30:25 +0000 Subject: [PATCH 17/53] UGRID text --- appk.adoc | 106 +++++----------------------------------------- bibliography.adoc | 2 +- ch01.adoc | 13 ++++++ 3 files changed, 24 insertions(+), 97 deletions(-) diff --git a/appk.adoc b/appk.adoc index 130e8825..f8592dfa 100644 --- a/appk.adoc +++ b/appk.adoc @@ -1,24 +1,13 @@ -[[appendix-mesh-topologies, Appendix K, Mesh topologies]] +[[appendix-mesh-topology-attributes, Appendix K, Mesh Topology Attributes]] [appendix] -== Mesh topologies +== Mesh Topologies -A mesh topology is the interconnection of various geometrical elements -of a domain on which data is defined. A __mesh topology variable__ -defines one or more domains, each of which has its own mesh topology, -and the topological connections between the domains are also -defined. For instance, <> -shows a mesh topology variable that defines a 2D triangular mesh -topology comprising three domains: one at the triangular element -nodes, one along the triangular element edges, and one on the -triangular faces. The nodes that define each edge, and the edges that -define each triangular face are also identified. - -A __location index set__ variable defines a subset of locations of another mesh topology, e.g. only boundary points or special locations like weirs and gates. -It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable. - -The canonical definitions of mesh topology and location index set variables are given by the UGRID conventions <>, but the standardized attributes, many of which are optional, are listed here for convenience. +The CF attributes listed here may be used to define mesh topologies +(<>). This list is intended as a summary of +the attributes that have been standardized via the UGRID conventions +<>, which should be consulted for further details. The "Type" values are **S** for string, and **I** for integer. The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables @@ -46,12 +35,12 @@ Attribute | **`coordinates`** | S | LIS -| Identifies the auxiliary coordinate variables associated with the characteristic location of the subset of mesh topology locations. +| Identifies the auxiliary coordinate variables associated with the characteristic locations of the subset of mesh topology locations. | **`edge_coordinates`** | S | MT -| Identifies the auxiliary coordinate variables associated with the characteristic location of the edge (commonly the midpoint). +| Identifies the auxiliary coordinate variables associated with the characteristic location of the edges (commonly the midpoint). | **`edge_dimension`** | I @@ -61,7 +50,7 @@ Attribute | **`edge_face_connectivity`** | S | MT -| Specifies an index variable identifying all faces that share the same edge, i. e. are neighbours to an edge. +| Specifies an index variable identifying all faces that share the same edge, i.e. are neighbours to an edge. | **`edge_node_connectivity`** | S @@ -116,7 +105,7 @@ Attribute | **`start_index`** | I | MT -| Indicates whether 0- or 1-based indexing is used to identify connect geometric elements; connectivity indices are 0-based by default. +| Indicates whether 0- or 1-based indexing is used to identify connected geometric elements; connectivity indices are 0-based by default. | **`topology_dimension`** | I @@ -158,78 +147,3 @@ Attribute | MT | Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. |=============== - - -[[cdl-mesh-topology-variable]] -[caption=""] -.Example K.1 A 2D triangular mesh topology variable. -==== ----- -dimensions: - nMesh2_node = 4 ; // nNodes - nMesh2_edge = 5 ; // nEdges - nMesh2_face = 2 ; // nFaces - -variables: - // Mesh topology variable - integer Mesh2 ; - Mesh2:cf_role = "mesh_topology" ; - Mesh2:long_name = "Topology data of 2D unstructured mesh" ; - Mesh2:topology_dimension = 2 ; - Mesh2:node_coordinates = "Mesh2_node_x Mesh2_node_y" ; - Mesh2:face_node_connectivity = "Mesh2_face_nodes" ; - Mesh2:face_dimension = "nMesh2_face" ; - Mesh2:edge_node_connectivity = "Mesh2_edge_nodes" ; - Mesh2:edge_dimension = "nMesh2_edge" ; - Mesh2:edge_coordinates = "Mesh2_edge_x Mesh2_edge_y" ; - Mesh2:face_coordinates = "Mesh2_face_x Mesh2_face_y" ; - Mesh2:face_edge_connectivity = "Mesh2_face_edges" ; - Mesh2:face_face_connectivity = "Mesh2_face_links" ; - Mesh2:edge_face_connectivity = "Mesh2_edge_face_links" ; - - // Connectivity variables - integer Mesh2_face_nodes(nMesh2_face, Three) ; - Mesh2_face_nodes:long_name = "Maps every triangular face to its three corner nodes." ; - integer Mesh2_edge_nodes(nMesh2_edge, Two) ; - Mesh2_edge_nodes:cf_role = "edge_node_connectivity" ; - Mesh2_edge_nodes:long_name = "Maps every edge to the two nodes that it connects." ; - integer Mesh2_face_edges(nMesh2_face, Three) ; - Mesh2_face_edges:cf_role = "face_edge_connectivity" ; - Mesh2_face_edges:long_name = "Maps every triangular face to its three edges." ; - integer Mesh2_face_links(nMesh2_face, Three) ; - Mesh2_face_links:cf_role = "face_face_connectivity" ; - Mesh2_face_links:long_name = "neighbor faces for faces" ; - Mesh2_face_links:_FillValue = -999 ; - Mesh2_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; - integer Mesh2_edge_face_links(nMesh2_edge, Two) ; - Mesh2_edge_face_links:cf_role = "edge_face_connectivity" ; - Mesh2_edge_face_links:long_name = "neighbor faces for edges" ; - Mesh2_edge_face_links:_FillValue = -999 ; - Mesh2_edge_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; - - // Data at faces, edges, and nodes - double volume_at_faces(nMesh2_face) ; - volume_at_faces:long_name = "volumes" ; - volume_at_faces:units = "m3" ; - volume_at_faces:mesh = "Mesh2" ; - volume_at_faces:location = "face" ; - volume_at_faces:coordinates = "Mesh2_face_x Mesh2_face_y" ; - double flux_at_edges(nMesh2_edge) ; - fluxe_at_edges:long_name = "flux across edge" ; - fluxe_at_edges:units = "m3 s-1" ; - fluxe_at_edges:mesh = "Mesh2" - fluxe_at_edges:location = "edge" ; - fluxe_at_edges:coordinates = "Mesh2_edge_x Mesh2_edge_y" ; - double volume_at_nodes(nMesh2_node) ; - volume_at_facess:long_name = "volumes" ; - volume_at_facess:units = "m3" ; - volume_at_facess:mesh = "Mesh2" ; - volume_at_facess:location = "node" ; - volume_at_facess:coordinates = "Mesh2_node_x Mesh2_node_y" ; ----- - -A mesh topology variable that defines a 2D triangular mesh topology comprising three domains: one at the triangular element nodes, one along the triangular element edges, and one on the triangular faces. -Each data variable selects exactly one of these for its domain. -The auxiliary coordinate variables identified by the **`node_coordinates`**, **`edge_coordinates`**, and **`face_coordinates`** mesh topology variable attributes have been omitted from the CDL for clarity. - -==== diff --git a/bibliography.adoc b/bibliography.adoc index b6689dc9..1782f141 100644 --- a/bibliography.adoc +++ b/bibliography.adoc @@ -30,4 +30,4 @@ - [[[W3C]]] link:$$http://www.w3.org/$$[World Wide Web Consortium (W3C)] . - [[[XML]]] link:$$http://www.w3.org/TR/1998/REC-xml-19980210$$[ Extensible Markup Language (XML) 1.0 ] . T. Bray, J. Paoli, and C.M. Sperberg-McQueen. 10 February 1998 . - [[[CFDM]]] link:$$http://doi.org/10.5194/gmd-10-4619-2017$$[ A data model of the Climate and Forecast metadata conventions (CF-1.6) with a software implementation (cf-python v2.1) ] . Hassell, D., Gregory, J., Blower, J., Lawrence, B. N., and Taylor, K. E.: Geosci. Model Dev., 10, 4619-4646, https://doi.org/10.5194/gmd-10-4619-2017, 2017. -- [[[UGRID]]] link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID Conventions for storing unstructured (or flexible mesh) data in the netCDF file] +- [[[UGRID]]] link:$$https://ugrid-conventions.github.io/ugrid-conventions$$[UGRID Conventions for storing unstructured (or flexible mesh) data in netCDF files] diff --git a/ch01.adoc b/ch01.adoc index 1b6da72c..33e065bb 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -180,3 +180,16 @@ The CF conventions define attributes which enable the description of data proper * Data compression for variables with missing values. + +[[ugrid-relationship, Section 1.6, "Relationship to the UGRID Conventions"]] +=== Relationship to the UGRID Conventions + +These conventions incorporate the UGRID-1.0 conventions for storing +unstructured (or flexible mesh) data in netCDF files <>. The +UGRID conventions description is referenced from, rather than +rewritten into, this document, i.e. the canonical description of how +to store mesh topologies is only to be found at <>. However, a +summary with examples are in <>, and to +reduce the chance of ambiguities arising from their accidential +re-use, all of the UGRID standardized attributes are specified in +<> and <>. \ No newline at end of file From 42be5910669719ef6f7c2c1b5f7695427a8335f4 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:32:15 +0000 Subject: [PATCH 18/53] UGRID text --- ch01.adoc | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/ch01.adoc b/ch01.adoc index 33e065bb..c080e2c9 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -184,12 +184,13 @@ The CF conventions define attributes which enable the description of data proper [[ugrid-relationship, Section 1.6, "Relationship to the UGRID Conventions"]] === Relationship to the UGRID Conventions -These conventions incorporate the UGRID-1.0 conventions for storing -unstructured (or flexible mesh) data in netCDF files <>. The -UGRID conventions description is referenced from, rather than -rewritten into, this document, i.e. the canonical description of how -to store mesh topologies is only to be found at <>. However, a -summary with examples are in <>, and to -reduce the chance of ambiguities arising from their accidential -re-use, all of the UGRID standardized attributes are specified in -<> and <>. \ No newline at end of file +These conventions implicitly incorporate the UGRID-1.0 conventions for +storing unstructured (or flexible mesh) data in netCDF files +<>. The UGRID conventions description is referenced from, +rather than rewritten into, this document, i.e. the canonical +description of how to store mesh topologies is only to be found at +<>. However, a summary with examples can be found in +<>, and to reduce the chance of ambiguities +arising from their accidential re-use, all of the UGRID standardized +attributes are specified in <> and +<>. \ No newline at end of file From e2285be88a29f91ae8b3bde09b6e52098f536212 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:36:15 +0000 Subject: [PATCH 19/53] UGRID text --- ch05.adoc | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/ch05.adoc b/ch05.adoc index 8a4c03af..3fde8396 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1070,15 +1070,17 @@ the <> example have been replaced by the domain variable [[mesh-topology-variables, Section 5.9, "Mesh Topology Variables"]] === Mesh Topology Variables -A mesh topology is the interconnection of various geometrical elements -of a domain on which data is defined. A __mesh topology variable__ -defines one or more domains, each of which has its own mesh topology, -and the topological connections between the domains are also defined. -A data variable may use one of a mesh topology variable's domains by -identifying the mesh topology variable alongside the required -constituent domain, typically specified as being the domain defined by -one of the nodes, edges, face or volumes of the mesh topology (see -example <>). +A mesh topology is the intra- and inter-connections of various +geometrical elements of one or more domains on which data are +defined. A __mesh topology variable__ defines a mesh topology for one +or more domains, i.e. each of domain defines the topological +connections between its own elements, and the topological connections +between the domains are also defined. A data variable may use one of a +mesh topology variable's domains by identifying the mesh topology +variable alongside the required constituent domain, typically +specified as being the domain defined by one of the nodes, edges, face +or volumes of the mesh topology (see example +<>). A __location index set__ variable defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations @@ -1153,11 +1155,11 @@ variables: fluxe_at_edges:location = "edge" ; fluxe_at_edges:coordinates = "Mesh2_edge_x Mesh2_edge_y" ; double height_at_nodes(nMesh2_node) ; - volume_at_faces:standard_name = "sea_surface_height_above_geoid" ; - volume_at_faces:units = "m" ; - volume_at_faces:mesh = "Mesh2" ; - volume_at_faces:location = "node" ; - volume_at_faces:coordinates = "Mesh2_node_x Mesh2_node_y" ; + height_at_nodes:standard_name = "sea_surface_height_above_geoid" ; + height_at_nodes:units = "m" ; + height_at_nodes:mesh = "Mesh2" ; + height_at_nodes:location = "node" ; + height_at_nodes:coordinates = "Mesh2_node_x Mesh2_node_y" ; ---- From 9c1292051169147bd8f2cae0e1a5ab3904d5cffd Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:37:38 +0000 Subject: [PATCH 20/53] UGRID text --- ch05.adoc | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/ch05.adoc b/ch05.adoc index 3fde8396..b462a3f0 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1071,16 +1071,15 @@ the <> example have been replaced by the domain variable === Mesh Topology Variables A mesh topology is the intra- and inter-connections of various -geometrical elements of one or more domains on which data are -defined. A __mesh topology variable__ defines a mesh topology for one -or more domains, i.e. each of domain defines the topological -connections between its own elements, and the topological connections -between the domains are also defined. A data variable may use one of a -mesh topology variable's domains by identifying the mesh topology -variable alongside the required constituent domain, typically -specified as being the domain defined by one of the nodes, edges, face -or volumes of the mesh topology (see example -<>). +geometrical elements of one or more domains. A __mesh topology +variable__ defines a mesh topology for one or more domains, i.e. each +of domain defines the topological connections between its own +elements, and the topological connections between the domains are also +defined. A data variable may use one of a mesh topology variable's +domains by identifying the mesh topology variable alongside the +required constituent domain, typically specified as being the domain +defined by one of the nodes, edges, face or volumes of the mesh +topology (see example <>). A __location index set__ variable defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations From 16f0167aece21d94234589e635a22a918acfec04 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:41:16 +0000 Subject: [PATCH 21/53] UGRID text --- ch05.adoc | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/ch05.adoc b/ch05.adoc index b462a3f0..48ddd28e 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1070,16 +1070,16 @@ the <> example have been replaced by the domain variable [[mesh-topology-variables, Section 5.9, "Mesh Topology Variables"]] === Mesh Topology Variables -A mesh topology is the intra- and inter-connections of various -geometrical elements of one or more domains. A __mesh topology -variable__ defines a mesh topology for one or more domains, i.e. each -of domain defines the topological connections between its own -elements, and the topological connections between the domains are also -defined. A data variable may use one of a mesh topology variable's -domains by identifying the mesh topology variable alongside the -required constituent domain, typically specified as being the domain -defined by one of the nodes, edges, face or volumes of the mesh -topology (see example <>). +A mesh topology is the intra- and inter-connections of the various +geometrical elements of a number of domains. A __mesh topology +variable__ defines a mesh topology for one or more domains, i.e. the +topological connections within each domain are defined, as well as the +topological connections between the domains. A data variable may use +one of a mesh topology variable's domains by identifying the mesh +topology variable alongside the required constituent domain, typically +specified as being the domain defined by one of the nodes, edges, face +or volumes of the mesh topology (see example +<>). A __location index set__ variable defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations From 6fbe7b2ad2e97ddcd8009f4d766762aec5349933 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 11:42:18 +0000 Subject: [PATCH 22/53] UGRID text --- ch05.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch05.adoc b/ch05.adoc index 48ddd28e..5d863d7f 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1093,7 +1093,7 @@ variables are given by the UGRID conventions <>, but the standardized attributes, many of which are optional, are listed in <> and <>. -[[example-mesh-topology-variabley]] +[[example-mesh-topology-variable]] [caption="Example 5.21. "] .Triangular mesh topology variable. ==== From 3119602805a3e081fce01a8b1429d4e733a1bef8 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 12:00:30 +0000 Subject: [PATCH 23/53] UGRID text --- ch01.adoc | 10 +++++----- ch05.adoc | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/ch01.adoc b/ch01.adoc index c080e2c9..268d5ff1 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -185,11 +185,11 @@ The CF conventions define attributes which enable the description of data proper === Relationship to the UGRID Conventions These conventions implicitly incorporate the UGRID-1.0 conventions for -storing unstructured (or flexible mesh) data in netCDF files -<>. The UGRID conventions description is referenced from, -rather than rewritten into, this document, i.e. the canonical -description of how to store mesh topologies is only to be found at -<>. However, a summary with examples can be found in +storing unstructured (or flexible mesh) data in netCDF files using +mesh topologies <>. The UGRID conventions description is +referenced from, rather than rewritten into, this document, i.e. the +canonical description of how to store mesh topologies is only to be +found at <>. However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidential re-use, all of the UGRID standardized attributes are specified in <> and diff --git a/ch05.adoc b/ch05.adoc index 5d863d7f..40bd520f 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1089,7 +1089,7 @@ variable, and as such is logically equivalent to a mesh topology variable (see example <>). The canonical definitions of mesh topology and location index set -variables are given by the UGRID conventions <>, but the +variables are given by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. From 5c68483ab6bf93c34292079b6386c973eda91ecb Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 12:39:57 +0000 Subject: [PATCH 24/53] UGRID text --- ch05.adoc | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/ch05.adoc b/ch05.adoc index 40bd520f..a5ccfebc 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1072,13 +1072,14 @@ the <> example have been replaced by the domain variable A mesh topology is the intra- and inter-connections of the various geometrical elements of a number of domains. A __mesh topology -variable__ defines a mesh topology for one or more domains, i.e. the -topological connections within each domain are defined, as well as the -topological connections between the domains. A data variable may use -one of a mesh topology variable's domains by identifying the mesh -topology variable alongside the required constituent domain, typically -specified as being the domain defined by one of the nodes, edges, face -or volumes of the mesh topology (see example +variable__ defines a mesh topology for one or more domains, i.e. +domain cells are defined with auxiliary coordinate variables and +topological connections within each domain are specified, as well as +the topological connections between the domains. A data variable may +use one of a mesh topology variable's domains by referencing the mesh +topology variable along with the identity of required domain, +typically specified as being the domain defined by one of the nodes, +edges, face or volumes of the mesh topology (see example <>). A __location index set__ variable defines a subset of locations of a From 99d0ca5732f5d03d48958f0c242780493abd3cbe Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 12:42:25 +0000 Subject: [PATCH 25/53] UGRID text --- ch05.adoc | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/ch05.adoc b/ch05.adoc index a5ccfebc..023cd4b9 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1079,10 +1079,10 @@ the topological connections between the domains. A data variable may use one of a mesh topology variable's domains by referencing the mesh topology variable along with the identity of required domain, typically specified as being the domain defined by one of the nodes, -edges, face or volumes of the mesh topology (see example +edges, faces or volumes of the mesh topology (see example <>). -A __location index set__ variable defines a subset of locations of a +A __location index set variable__ defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations like weirs and gates. It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology @@ -1163,7 +1163,7 @@ variables: ---- -A mesh topology variable that defines a 2D triangular mesh topology comprising three domains: one at the triangular element nodes, one along the triangular element edges, and one on the triangular faces. +This example shows a mesh topology variable that defines a 2D triangular mesh topology comprising three domains: one at the triangular element nodes, one along the triangular element edges, and one on the triangular faces. Each data variable selects exactly one of these for its domain. The auxiliary coordinate variables identified by the **`node_coordinates`**, **`edge_coordinates`**, and **`face_coordinates`** mesh topology variable attributes have been omitted from the CDL for clarity. @@ -1193,6 +1193,7 @@ variables: Mesh2_waterlevel:location_index_set = "Mesh2_set" ; ---- -The mesh topology variable `Mesh2`, defined in example <>, has four nodes, two of which are used here to define the new domain in `Mesh2_set`. +This example shows a domain defined by a location index set variable. +The mesh topology variable `Mesh2`, not shown but as defined in example <>, has four nodes, two of which are used here to define the new domain in `Mesh2_set`. ==== From fd33a22583719a1e2a349b1f77ab9bdffb7f6f14 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 12:43:40 +0000 Subject: [PATCH 26/53] UGRID text --- ch05.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ch05.adoc b/ch05.adoc index 023cd4b9..f1033f65 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1089,14 +1089,14 @@ prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable (see example <>). -The canonical definitions of mesh topology and location index set -variables are given by the UGRID conventions <>, but their -standardized attributes, many of which are optional, are listed in -<> and <>. +The canonical definitions of mesh topology variables and location +index set variables are given by the UGRID conventions <>, but +their standardized attributes, many of which are optional, are listed +in <> and <>. [[example-mesh-topology-variable]] [caption="Example 5.21. "] -.Triangular mesh topology variable. +.Triangular mesh topology variable ==== ---- dimensions: From 9e21a26d2e74ef4d54a9b9d866d4bd63f4a040e9 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 13:35:04 +0000 Subject: [PATCH 27/53] UGRID text --- ch01.adoc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ch01.adoc b/ch01.adoc index 268d5ff1..9c40841f 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -193,4 +193,8 @@ found at <>. However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidential re-use, all of the UGRID standardized attributes are specified in <> and -<>. \ No newline at end of file +<>. + +The UGRID conventions have their own conformance document, which +should be used in conjunction with the CF conformance document when +checking the validity of datasets. \ No newline at end of file From 57b2d424ea453225cc15fea9054c73da7c4896a7 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 14:32:45 +0000 Subject: [PATCH 28/53] UGRID text --- appa.adoc | 10 +++++----- appi.adoc | 2 +- appk.adoc | 16 ++++++++-------- ch01.adoc | 14 ++++---------- ch05.adoc | 31 ++++++++----------------------- 5 files changed, 26 insertions(+), 47 deletions(-) diff --git a/appa.adoc b/appa.adoc index ccacb0c7..2f4c0721 100644 --- a/appa.adoc +++ b/appa.adoc @@ -81,7 +81,7 @@ Attribute | S | C, - | <> -| Identifies the roles of variables that identify features in discrete sampling geometries +| Identifies the roles of variables that identify features in discrete sampling geometries; and the roles of mesh topology and location index set variables | **`climatology`** | S @@ -234,13 +234,13 @@ formula in the definition. | **`location`** | S | D, Do -| <> and <> -| Specifies the (stagger) location within the mesh topology that at which the variable is defined. +| <> and <> +| Specifies the location type within the mesh topology at which the variable is defined. | **`location_index_set`** | S | D, Do -| <> and <> +| <> and <> | Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`long_name`** @@ -252,7 +252,7 @@ formula in the definition. | **`mesh`** | S | D, Do -| <> and <> +| <> and <> | Specifies a variable that defines a mesh topology. | **`missing_value`** diff --git a/appi.adoc b/appi.adoc index dcc4a24a..4ee2d77f 100644 --- a/appi.adoc +++ b/appi.adoc @@ -116,7 +116,7 @@ CF-netCDF element | Metadata that depends on the domain | Mesh topology variable -| Connectivity of domain cells +| Domain(s) with cell connectivity | Formula terms attribute | Vertical coordinate system diff --git a/appk.adoc b/appk.adoc index f8592dfa..6f4d4940 100644 --- a/appk.adoc +++ b/appk.adoc @@ -25,27 +25,27 @@ Attribute | **`boundary_node_connectivity`** | S | MT -| Specifies an index variable identifying for every edge of each boundary the two nodes that it connects. (DCH - what is "the boundary") +| Specifies an index variable identifying the nodes that each boundary element (i.e. the nodes that defin each edge of a face, or the nodes that define each face of a volume). | **`cf_role`** | S | MT, LIS -| ?? +| Specifies the roles of mesh topology or location index set variables. | **`coordinates`** | S | LIS -| Identifies the auxiliary coordinate variables associated with the characteristic locations of the subset of mesh topology locations. +| Specifies the auxiliary coordinate variables associated with the characteristic locations of the subset of mesh topology locations. | **`edge_coordinates`** | S | MT -| Identifies the auxiliary coordinate variables associated with the characteristic location of the edges (commonly the midpoint). +| Specifies the auxiliary coordinate variables associated with the characteristic location of the edges (commonly the midpoint). | **`edge_dimension`** | I | MT -| Identifies the dimension used to indicate the index of the edge in the connectivity arrays. +| Specify the position of the dimension used to index the nodes in the edge connectivity variable. | **`edge_face_connectivity`** | S @@ -65,7 +65,7 @@ Attribute | **`face_dimension`** | I | MT -| ?? +| Specify the position of the dimension used to index the edges in the face connectivity variable. | **`face_edge_connectivity`** | S @@ -85,7 +85,7 @@ Attribute | **`location`** | S | LIS, D, Do -| Specifies the (stagger) location within the mesh topology that at which the variable is defined. +| Specifies the location within the mesh topology at which the variable is defined. | **`location_index_set`** | S @@ -120,7 +120,7 @@ Attribute | **`volume_dimension`** | I | MT -| ?? +| Specify the position of the dimension used to index the faces in the volume connectivity variable. | **`volume_edge_connectivity`** | S diff --git a/ch01.adoc b/ch01.adoc index 9c40841f..2df2fc0a 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -184,16 +184,10 @@ The CF conventions define attributes which enable the description of data proper [[ugrid-relationship, Section 1.6, "Relationship to the UGRID Conventions"]] === Relationship to the UGRID Conventions -These conventions implicitly incorporate the UGRID-1.0 conventions for -storing unstructured (or flexible mesh) data in netCDF files using -mesh topologies <>. The UGRID conventions description is -referenced from, rather than rewritten into, this document, i.e. the -canonical description of how to store mesh topologies is only to be -found at <>. However, a summary with examples can be found in -<>, and to reduce the chance of ambiguities -arising from their accidential re-use, all of the UGRID standardized -attributes are specified in <> and -<>. +These conventions implicitly incorporate the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. +Only version 1.0 of the UGRID conventions is allowed. +The UGRID conventions description is referenced from, rather than rewritten into, this document, i.e. the canonical description of how to store mesh topologies is only to be found at <>. +However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidential re-use, all of the UGRID standardized attributes are specified in <> and <>. The UGRID conventions have their own conformance document, which should be used in conjunction with the CF conformance document when diff --git a/ch05.adoc b/ch05.adoc index f1033f65..7896272e 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1070,29 +1070,14 @@ the <> example have been replaced by the domain variable [[mesh-topology-variables, Section 5.9, "Mesh Topology Variables"]] === Mesh Topology Variables -A mesh topology is the intra- and inter-connections of the various -geometrical elements of a number of domains. A __mesh topology -variable__ defines a mesh topology for one or more domains, i.e. -domain cells are defined with auxiliary coordinate variables and -topological connections within each domain are specified, as well as -the topological connections between the domains. A data variable may -use one of a mesh topology variable's domains by referencing the mesh -topology variable along with the identity of required domain, -typically specified as being the domain defined by one of the nodes, -edges, faces or volumes of the mesh topology (see example -<>). - -A __location index set variable__ defines a subset of locations of a -mesh topology variable, e.g. only boundary points or special locations -like weirs and gates. It is provided as a space saving device to -prevent the need to redefine parts of an existing mesh topology -variable, and as such is logically equivalent to a mesh topology -variable (see example <>). - -The canonical definitions of mesh topology variables and location -index set variables are given by the UGRID conventions <>, but -their standardized attributes, many of which are optional, are listed -in <> and <>. +A mesh topology is the intra- and inter-connections of the various geometrical elements of a number of domains. +A __mesh topology variable__ defines a mesh topology for one or more domains, i.e. domain cells are defined with auxiliary coordinate variables and topological connections within each domain are specified, as well as the topological connections between the domains. +A data variable may use one of a mesh topology variable's domains by referencing the mesh topology variable along with the identity of required domain, typically specified as being the domain defined by one of the nodes, edges, faces or volumes of the mesh topology (see example <>). + +A __location index set variable__ defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations like weirs and gates. +It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable (see example <>). + +The canonical definitions of mesh topology variables and location index set variables are given by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. [[example-mesh-topology-variable]] [caption="Example 5.21. "] From 49516fa69bcf2b693d9fe785964de7994060cbaf Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 14:35:19 +0000 Subject: [PATCH 29/53] UGRID text --- appa.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/appa.adoc b/appa.adoc index 2f4c0721..2fbbc252 100644 --- a/appa.adoc +++ b/appa.adoc @@ -234,13 +234,13 @@ formula in the definition. | **`location`** | S | D, Do -| <> and <> +| <> and <> | Specifies the location type within the mesh topology at which the variable is defined. | **`location_index_set`** | S | D, Do -| <> and <> +| <> and <> | Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`long_name`** @@ -252,7 +252,7 @@ formula in the definition. | **`mesh`** | S | D, Do -| <> and <> +| <> and <> | Specifies a variable that defines a mesh topology. | **`missing_value`** From 85c030704e5698a20a1fa3f3c785329945a11ef1 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 14:36:03 +0000 Subject: [PATCH 30/53] UGRID text --- appk.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/appk.adoc b/appk.adoc index 6f4d4940..5b7215e9 100644 --- a/appk.adoc +++ b/appk.adoc @@ -45,7 +45,7 @@ Attribute | **`edge_dimension`** | I | MT -| Specify the position of the dimension used to index the nodes in the edge connectivity variable. +| Specifies the position of the dimension used to index the nodes in the edge connectivity variable. | **`edge_face_connectivity`** | S @@ -65,7 +65,7 @@ Attribute | **`face_dimension`** | I | MT -| Specify the position of the dimension used to index the edges in the face connectivity variable. +| Specifies the position of the dimension used to index the edges in the face connectivity variable. | **`face_edge_connectivity`** | S @@ -120,7 +120,7 @@ Attribute | **`volume_dimension`** | I | MT -| Specify the position of the dimension used to index the faces in the volume connectivity variable. +| Specifies the position of the dimension used to index the faces in the volume connectivity variable. | **`volume_edge_connectivity`** | S From 8189ec95f55091a60453eb3d9907d5d74ae10dd7 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 15:03:37 +0000 Subject: [PATCH 31/53] UGRID text --- appa.adoc | 8 ++++---- ch01.adoc | 4 ++-- ch05.adoc | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/appa.adoc b/appa.adoc index 2fbbc252..10b701dc 100644 --- a/appa.adoc +++ b/appa.adoc @@ -80,7 +80,7 @@ Attribute | **`cf_role`** | S | C, - -| <> +| <>, <> | Identifies the roles of variables that identify features in discrete sampling geometries; and the roles of mesh topology and location index set variables | **`climatology`** @@ -234,13 +234,13 @@ formula in the definition. | **`location`** | S | D, Do -| <> and <> +| <>, <> | Specifies the location type within the mesh topology at which the variable is defined. | **`location_index_set`** | S | D, Do -| <> and <> +| <>, <> | Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`long_name`** @@ -252,7 +252,7 @@ formula in the definition. | **`mesh`** | S | D, Do -| <> and <> +| <>, <> | Specifies a variable that defines a mesh topology. | **`missing_value`** diff --git a/ch01.adoc b/ch01.adoc index 2df2fc0a..d706d3a0 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -181,8 +181,8 @@ The CF conventions define attributes which enable the description of data proper * Data compression for variables with missing values. -[[ugrid-relationship, Section 1.6, "Relationship to the UGRID Conventions"]] -=== Relationship to the UGRID Conventions +[[ugrid-conventions, Section 1.6, "UGRID Conventions"]] +=== UGRID Conventions These conventions implicitly incorporate the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. Only version 1.0 of the UGRID conventions is allowed. diff --git a/ch05.adoc b/ch05.adoc index 7896272e..66dc7afa 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1070,7 +1070,7 @@ the <> example have been replaced by the domain variable [[mesh-topology-variables, Section 5.9, "Mesh Topology Variables"]] === Mesh Topology Variables -A mesh topology is the intra- and inter-connections of the various geometrical elements of a number of domains. +A mesh topology is the intra- and inter-connections of the various geometrical elements of a number of related domains. A __mesh topology variable__ defines a mesh topology for one or more domains, i.e. domain cells are defined with auxiliary coordinate variables and topological connections within each domain are specified, as well as the topological connections between the domains. A data variable may use one of a mesh topology variable's domains by referencing the mesh topology variable along with the identity of required domain, typically specified as being the domain defined by one of the nodes, edges, faces or volumes of the mesh topology (see example <>). From 0b2fbdad0c834fee9d688c0aa3c394208e1cd8a0 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 15:05:33 +0000 Subject: [PATCH 32/53] UGRID text --- appa.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/appa.adoc b/appa.adoc index 10b701dc..a49140c6 100644 --- a/appa.adoc +++ b/appa.adoc @@ -234,13 +234,13 @@ formula in the definition. | **`location`** | S | D, Do -| <>, <> +| <>, and <> | Specifies the location type within the mesh topology at which the variable is defined. | **`location_index_set`** | S | D, Do -| <>, <> +| <>, and <> | Specifies a variable that defines the subset of locations of a mesh topology at which the variable is defined. | **`long_name`** @@ -252,7 +252,7 @@ formula in the definition. | **`mesh`** | S | D, Do -| <>, <> +| <>, and <> | Specifies a variable that defines a mesh topology. | **`missing_value`** From 89782ac32a95daabaa1d2d4f5841f7f18484d385 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 15:08:40 +0000 Subject: [PATCH 33/53] UGRID text --- appa.adoc | 2 +- toc-extra.adoc | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/appa.adoc b/appa.adoc index a49140c6..2c5e4f4c 100644 --- a/appa.adoc +++ b/appa.adoc @@ -80,7 +80,7 @@ Attribute | **`cf_role`** | S | C, - -| <>, <> +| <>, and <> | Identifies the roles of variables that identify features in discrete sampling geometries; and the roles of mesh topology and location index set variables | **`climatology`** diff --git a/toc-extra.adoc b/toc-extra.adoc index be517d6d..50309e1c 100644 --- a/toc-extra.adoc +++ b/toc-extra.adoc @@ -11,6 +11,7 @@ E.1. <> F.1. <> I.1. <> I.2. <> +K.2. <> **List of Examples** From a0be36c088a4c1793fe8681e3d04960e7d3ade28 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 20 Jan 2022 15:16:56 +0000 Subject: [PATCH 34/53] UGRID text --- conformance.adoc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/conformance.adoc b/conformance.adoc index cfc78e30..c891a00d 100644 --- a/conformance.adoc +++ b/conformance.adoc @@ -14,6 +14,13 @@ conventions document is the ultimate authority. * This document will be updated as required to correct mistakes or add new material required for completeness or clarity. +=== UGRID Conventions + +Requirements and recommendations relating to the UGRID conventions for +storing unstructured (or flexible mesh) data in netCDF files are not +described here, but are nonetheless considered as part of the CF +conformance requirements and recommendations. See <> +for the UGRID conformance requirements and recommendations. [[filename]] === 2.1 Filename From d0377b02d78f455698283140564f38db528602a8 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Fri, 21 Jan 2022 09:45:07 +0000 Subject: [PATCH 35/53] typo --- ch01.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.adoc b/ch01.adoc index d706d3a0..a704c309 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -187,7 +187,7 @@ The CF conventions define attributes which enable the description of data proper These conventions implicitly incorporate the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. Only version 1.0 of the UGRID conventions is allowed. The UGRID conventions description is referenced from, rather than rewritten into, this document, i.e. the canonical description of how to store mesh topologies is only to be found at <>. -However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidential re-use, all of the UGRID standardized attributes are specified in <> and <>. +However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. The UGRID conventions have their own conformance document, which should be used in conjunction with the CF conformance document when From 3f9b4d53421f7da8c380c7e489e7713140edc60a Mon Sep 17 00:00:00 2001 From: David Hassell Date: Fri, 21 Jan 2022 13:20:21 +0000 Subject: [PATCH 36/53] describe relationship between domain construct and CF-netCDF variables --- appi.adoc | 37 ++++++++++++++++++++++++------------- images/cfdm_cf_concepts.gv | 6 +++++- 2 files changed, 29 insertions(+), 14 deletions(-) diff --git a/appi.adoc b/appi.adoc index 4ee2d77f..f6273083 100644 --- a/appi.adoc +++ b/appi.adoc @@ -116,7 +116,10 @@ CF-netCDF element | Metadata that depends on the domain | Mesh topology variable -| Domain(s) with cell connectivity +| One or more related domains with cell connectivity + +| Location index set variable +| A domain with cell connectivity | Formula terms attribute | Vertical coordinate system @@ -293,11 +296,18 @@ construct) and relates the following metadata constructs All of the constructs contained by the domain construct are optional (as indicated by "0.." in <>). -In CF-netCDF, domain information is stored either implicitly via data -variable attributes (such as `coordinates`), or explicitly in a domain -variable. In the latter case, the domain exists without reference to a -data array. +In CF-netCDF, domain information may be stored in a number of ways: + +* implicitly via data variable attributes (such as `coordinates`); + +* explicitly in a domain variable; + +* explicitly in a mesh topology variable, in which case the domain may be one of multiple domains defined by the same variable (for instance, a single mesh topology variable could contain different domains defined respectively at node, edge, and face elements); + +* explicitly in a location index set variable that references a subset of another domain defined by a mesh topology variable. +For the explicit cases, the domain exists without reference to a data array. + [[data-model-domain-axis-construct-and-the-data-array]] ==== Domain axis construct and the data array @@ -334,7 +344,7 @@ of the domain axis constructs, properties to describe the coordinates (in the same sense as for the field construct), an optional data array of cell bounds recording the extents of each cell, and any extra arrays needed to interpret the cell bounds values. The data array of -the coordinate values is required, execpt for the special cases +the coordinate values is required, except for the special cases described below. There are two distinct types of coordinate construct: dimension @@ -636,13 +646,14 @@ that is external to CF. In CF-netCDF a domain topology can only be provided for a domain defined by a UGRID mesh topology variable. In this case, the connectivity array is supplied by a UGRID connectivity variable, such -as a "face_face_connectivity" variable. The information represented by -the symmetrical connectivity array of the domain topology construct in -the CF data model is stored in a different but equivalent way in -UGRID. The trailing dimension of a UGRID connectivity variable's data -records, for each cell, the indices of the other cells to which it is -connected (padded with missing data if a cell has fewer connections -than some others). +as a "face_face_connectivity" variable, that is referenced from a mesh +topology variable. The information represented by the symmetrical +connectivity array of the domain topology construct in the CF data +model is stored in a different but equivalent way in UGRID. The +trailing dimension of a UGRID connectivity variable's data records, +for each cell, the indices of the other cells to which it is connected +(padded with missing data if a cell has fewer connections than some +others). [[data-model-field-ancillary]] ==== Field ancillary constructs diff --git a/images/cfdm_cf_concepts.gv b/images/cfdm_cf_concepts.gv index 9ec6afa0..40858c23 100644 --- a/images/cfdm_cf_concepts.gv +++ b/images/cfdm_cf_concepts.gv @@ -52,6 +52,7 @@ AncillaryData [label="Ancillary\nData\nVariable"] BoundaryVariable [label="Boundary\nVariable"] GridMapping [label="Grid\nMapping\nVariable"] MeshTopology [label="Mesh\nTopology\nVariable"] +LocationIndexSet [label="Location\nIndex Set\nVariable"] # -------------------------------------------------------------------- # Invisible nodes used to aid in layout @@ -78,6 +79,7 @@ route12 route13 route14 route15 +route16 edge [arrowtail=none arrowhead=none @@ -121,8 +123,10 @@ route9 -> route10 [] route10 -> AncillaryData [weight=100] route10 -> route15 [] route15 -> MeshTopology [weight=100] +route15 -> route16 [] +route16 -> LocationIndexSet [weight=100] -{rank=same; route4, route5, route6, route7, route8, route9, route10, route15} +{rank=same; route4, route5, route6, route7, route8, route9, route10, route15, route16} {rank=same; GenericCoordinate, BoundaryVariable, Data, Domain, CellMeasure, AncillaryData GridMapping} GenericCoordinate -> BoundaryVariable [arrowhead=vee arrowtail=none minlen=2 headlabel="0..1 "] From c401fae05d15f4aba7df1a2fe69163a8f00d389e Mon Sep 17 00:00:00 2001 From: David Hassell Date: Fri, 21 Jan 2022 13:21:43 +0000 Subject: [PATCH 37/53] describe relationship between domain construct and CF-netCDF variables --- images/cfdm_cf_concepts.svg | 73 ++++++++++++++++++++++++------------- 1 file changed, 48 insertions(+), 25 deletions(-) diff --git a/images/cfdm_cf_concepts.svg b/images/cfdm_cf_concepts.svg index 9cd567e4..b73efc19 100644 --- a/images/cfdm_cf_concepts.svg +++ b/images/cfdm_cf_concepts.svg @@ -4,11 +4,11 @@ - + %3 - + NetCDFDimension @@ -43,7 +43,7 @@ 0..*     - + route7 @@ -70,14 +70,14 @@ Variable - + GenericCoordinate->BoundaryVariable 0..1     - + route4 @@ -87,12 +87,12 @@ - + route12 - + GenericCoordinate->route12 @@ -104,7 +104,7 @@ Dimension - + route3 @@ -120,7 +120,7 @@ Cell Methods - + route1 @@ -130,7 +130,7 @@ - + route2 @@ -140,7 +140,7 @@ - + route11 @@ -225,7 +225,7 @@ Variable - + route8 @@ -242,6 +242,14 @@ Topology Variable + + +LocationIndexSet + +Location +Index Set +Variable + route1->NetCDFDimension @@ -262,7 +270,7 @@ - + route5 @@ -277,7 +285,7 @@ - + route6 @@ -307,7 +315,7 @@ - + route9 @@ -322,7 +330,7 @@ - + route10 @@ -337,7 +345,7 @@ - + route15 @@ -353,37 +361,37 @@ - + route12->AuxiliaryCoordinate - + route13 - + route12->route13 - + route13->Coordinate - + route14 - + route13->route14 - + route14->ScalarCoordinate @@ -392,5 +400,20 @@ route15->MeshTopology + + +route16 + + + + +route15->route16 + + + + +route16->LocationIndexSet + + From 2323be3c052da78c435e145e27fd9c2a33ae97b4 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Fri, 5 May 2023 11:09:04 +0100 Subject: [PATCH 38/53] initial boundary condition draft --- appk.adoc | 7 ++++++- ch01.adoc | 4 +--- ch05.adoc | 4 +++- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/appk.adoc b/appk.adoc index 5b7215e9..0826c4ca 100644 --- a/appk.adoc +++ b/appk.adoc @@ -9,7 +9,7 @@ The CF attributes listed here may be used to define mesh topologies the attributes that have been standardized via the UGRID conventions <>, which should be consulted for further details. -The "Type" values are **S** for string, and **I** for integer. +The "Type" values are **S** for string, **I** for integer, and **D** for the type of the variable. The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables [[table-mesh-topology-attributes]] @@ -22,6 +22,11 @@ Attribute | Use | Description +| **`boundary_condition`** +| D +| D +| Specifies an variable that defines the boundary condition for each boundary identified by the `boundary_node_connectivity` attribute of the mesh topology variable. + | **`boundary_node_connectivity`** | S | MT diff --git a/ch01.adoc b/ch01.adoc index a704c309..9eb3a0e4 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -189,6 +189,4 @@ Only version 1.0 of the UGRID conventions is allowed. The UGRID conventions description is referenced from, rather than rewritten into, this document, i.e. the canonical description of how to store mesh topologies is only to be found at <>. However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. -The UGRID conventions have their own conformance document, which -should be used in conjunction with the CF conformance document when -checking the validity of datasets. \ No newline at end of file +The UGRID conventions have their own conformance document, which should be used in conjunction with the CF conformance document when checking the validity of datasets. \ No newline at end of file diff --git a/ch05.adoc b/ch05.adoc index 66dc7afa..6f772ca5 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1077,7 +1077,9 @@ A data variable may use one of a mesh topology variable's domains by referencing A __location index set variable__ defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations like weirs and gates. It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable (see example <>). -The canonical definitions of mesh topology variables and location index set variables are given by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. +When a data variable's domain is defined by a mesh topology variable it is possible to provide, at selected domain locations, the boundary conditions which constrain the data. + +The canonical definitions of mesh topology variables, location index set variables and boundary condition variables are given by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. [[example-mesh-topology-variable]] [caption="Example 5.21. "] From 1a3fecd149b35ed74081cc7c528a0495c4ae2709 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Tue, 12 Sep 2023 10:20:24 +0100 Subject: [PATCH 39/53] dev --- appi.adoc | 105 ++++++++++++++++++++++++++++++++++-------------------- appk.adoc | 36 ++++++++----------- ch01.adoc | 4 +-- 3 files changed, 83 insertions(+), 62 deletions(-) diff --git a/appi.adoc b/appi.adoc index f6273083..8103479f 100644 --- a/appi.adoc +++ b/appi.adoc @@ -184,6 +184,9 @@ CF construct | Cell size or shape | Domain topology +| Geospatial topology of domain cells + +| Cell connectivity | Connectivity of domain cells | Field ancillary @@ -293,6 +296,8 @@ construct) and relates the following metadata constructs * Domain topology constructs. +* Cell connectivity constructs. + All of the constructs contained by the domain construct are optional (as indicated by "0.." in <>). @@ -302,7 +307,7 @@ In CF-netCDF, domain information may be stored in a number of ways: * explicitly in a domain variable; -* explicitly in a mesh topology variable, in which case the domain may be one of multiple domains defined by the same variable (for instance, a single mesh topology variable could contain different domains defined respectively at node, edge, and face elements); +* explicitly in a mesh topology variable, in which case the domain may be one of multiple domains defined by the same variable (for instance, a single mesh topology variable could contain different domains defined respectively at node, edge, and face mesh elements); * explicitly in a location index set variable that references a subset of another domain defined by a mesh topology variable. @@ -614,46 +619,68 @@ domain which are not spanned by the array, along which the values are implicitly propagated. CF-netCDF cell measure variables correspond to cell measure constructs. -[[data-model-domain_topology]] +[[data-model-domain-topology]] ==== Domain topology construct -A domain topology describes the connectivity of domain cells indexed -by a subset of the domain axis constructs. When two cells are -connected, operations on the data stored on them may be assumed to be -continuous across their common boundary. A domain topology construct -(<>) describes logically and explicitly the -domain topology of cells indexed by a single domain axis construct. - -A domain topology construct contains a connectivity array that spans a -single domain axis construct with the addition of an extra dimension -of the same size, such that each dimension indexes the cells. The -array is symmetrical, and each element indicates whether the pair of -cells to which its indices refer are connected. The connectivity of a -cell to itself is undefined, so the diagonal elements of this array -are ignored. A domain construct may contain at most one domain -topology construct. - -For any subset of the domain axis constructs, excluding a domain axis -construct for which there is a domain topology construct, there is an -implicit domain topology that is defined by a function of the physical -contiguousness of the cells, and/or the nature of the real world or -simulated processes that produced the data. For example, in a field -which contains both land and ocean cells, connections between land and -ocean cells might be excluded for some physical processes. The -description of such an implicit network topology may require metadata -that is external to CF. - -In CF-netCDF a domain topology can only be provided for a domain -defined by a UGRID mesh topology variable. In this case, the -connectivity array is supplied by a UGRID connectivity variable, such -as a "face_face_connectivity" variable, that is referenced from a mesh -topology variable. The information represented by the symmetrical -connectivity array of the domain topology construct in the CF data -model is stored in a different but equivalent way in UGRID. The -trailing dimension of a UGRID connectivity variable's data records, -for each cell, the indices of the other cells to which it is connected -(padded with missing data if a cell has fewer connections than some -others). +A domain topology construct defines the geospatial topology of cells arranged in two or three dimensions in real space but indexed by a single (discrete) domain axis construct, and at most one domain topology construct may be associated with any such domain axis. +The topology describes topological relationships between the cells - spatial relationships which do not depend on the cell locations - and is represented by an undirected graph, i.e. a mesh in which pairs of nodes are connected by links. +Each node has a unique arbitrary identity that is independent of its spatial location, and different nodes may be spatially co-located. + +The topology may only describe cells that have a common spatial dimensionality, one of: + +* Point: A point is zero-dimensional and has no boundary vertices. +* Edge: An edge is one-dimensional and corresponds to a line connecting two boundary vertices. +* Face: A face is two-dimensional and corresponds to a surface enclosed by a set of edges. + +Each type of cell implies a restricted topology for which only some kinds of mesh are allowed. +For point cells, every node corresponds to exactly one cell; and two cells have a topological relationship if and only if their nodes are connected by a mesh link. +For edge and face cells, every node corresponds to a boundary vertex of a cell; the same node can represent vertices in multiple cells; every link in the mesh connects two cell boundary vertices; and two cells have a topological relationship if and only if they share at least one node. + +[[figure-mesh-example]] +[caption="Figure {doc-part}.{counter:figure}. ", reftext=Figure {doc-part}.{figure}] +[.text-center] +.A topology defined by a mesh with five nodes and six links. +image::images/cfdm_mixed_mesh.png[,100%,pdfwidth=50vw,align="center"] + +For example, the mesh depicted in <> may be used with any of three domain topology constructs for domains comprising two face cells (one triangle and one quadrilateral), six edge cells, and five point cells respectively. + +A domain topology construct contains an array defining the mesh, and properties to describe it. +There must be a property indicating the spatial dimensionality of the cells. +The array values comprise the node identities, and all array elements that refer to the same node must contain the same value, which must differ from any other value in the array. +The array spans the domain axis construct and also has a ragged dimension, whose function depends on the spatial dimensionality of the cells. + +For point cells, the array's ragged dimension values are composed of the node identity of each cell in the first element, followed in arbitrary order by the identity of each node to which it is connected by a mesh link. + +For edge and face cells, the array's ragged dimension values are the node identities of the boundary vertices of each cell, in the same order that the boundary vertices are stored by the auxiliary coordinate constructs. +Each boundary vertex except the last is connected by a mesh link to the next vertex along the ragged dimension, and the last vertex is connected to the first. + +When a domain topology construct is present it is considered to be definitive and must be used in preference to the topology implied by inspection of any other constructs, which is not guaranteed to be the same. + +In CF-netCDF a domain topology construct can only be provided for a UGRID mesh topology variable. +The information in the construct array is supplied by the UGRID "edge_nodes_connectivity" variable (for edge cells) or "face_nodes_connectivity" variable (for face cells). +The topology for node cells may be provided by any of these three UGRID variables. +The integer indices contained in the UGRID variable may be used as the mesh node identities, although the CF data model attaches no significance to the values other than the fact that some values are the same as others. +The spatial dimensionality property is provided by the "location" attribute of a variable that references the UGRID mesh topology variable, i.e. a data variable or a UGRID location index set variable. + +A single UGRID mesh topology defines multiple domain constructs and defines how they relate to each other. +For instance, when "face_node_connectivity" and "edge_node_connectivity" variables are both present there are three implied domain constructs - one each for face, edge and point cells - all of which have the same mesh and so are explicitly linked (e.g. it is known which edge cells define each face cell). +The CF data model has no mechanism for explicitly recording such relationships between multiple domain constructs, however whether or not two domains have the same mesh may be reliably deternined by inspection, thereby allowing the creation of netCDF datasets containing UGRID mesh topology variables. + +The restrictions on the type of mesh that may be used with a given cell spatial dimensionality excludes some meshes which can be described by an undirected graph, but is consistent with UGRID encoding within CF-netCDF. +UGRID also describes meshes for three-dimensional volume cells that correspond to a volume enclosed by a set of faces, but how the nodes relate to volume boundary vertices is undefined and so volume cells are currently omitted from the CF data model. + +[[data-model-cell-connectivity]] +==== Cell connectivity construct + +A cell connectivity construct defines explicitly how cells arranged in two or three dimensions in real space but indexed by a single domain (discrete) axis are connected. Connectivity can only be provided when the domain axis construct also has a domain topology construct, and two cells can only be connected if they also have a topological relationship. For instance, the connectivity of two-dimensional face cells could be characterised by whether or not they have shared edges, where the edges are defined by connected nodes of the domain topology construct. + +The cell connectivity construct consists of an array recording the connectivity, and properties to describe the data. There must be a property indicating the condition by which the connectivity is derived from the domain topology. The array spans the domain axis construct with the addition of a ragged dimension that indexes a unique identity for the cell as well as the identities of all other cells to which it is connected. The cell identity must be recorded in the first element of the ragged dimension, otherwise the order is arbitrary. Note that the connectivity array for point cells is, by definition, equivalent to the array of the domain topology construct. + +When cell connectivity constructs are present they are considered to be definitive and must be used in preference to the connectivities implied by inspection of any other constructs, apart from the domain topology construct, which are not guaranteed to be the same. + +In CF-netCDF a cell topology construct can only be provided by a UGRID mesh topology variable. The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "edge_edge_connectivity" variable (for edge cells) or "face_face_connectivity" variable (for face cells). In the direct case, the integer indices contained in the UGRID variable may be used as the cell identities, although the CF data model attaches no significance to the values other than the fact that some values are the same as others. + +Restricting the types of connectivity to those implied by the geospatial topology of the cells precludes connectivity derived from any other sources, but is consistent with UGRID encoding within CF-netCDF. [[data-model-field-ancillary]] ==== Field ancillary constructs diff --git a/appk.adoc b/appk.adoc index 0826c4ca..15a455ed 100644 --- a/appk.adoc +++ b/appk.adoc @@ -4,13 +4,12 @@ [appendix] == Mesh Topologies -The CF attributes listed here may be used to define mesh topologies -(<>). This list is intended as a summary of -the attributes that have been standardized via the UGRID conventions -<>, which should be consulted for further details. +The CF attributes listed here may be used to define mesh topologies (<>). +This list is intended as a summary of the attributes that have been standardized via the UGRID conventions <>, which should be consulted for further details. +UGRID attributes that are not currently recognised by the CF convensions are included in the list. -The "Type" values are **S** for string, **I** for integer, and **D** for the type of the variable. -The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, and **Do** for domain variables +The "Type" values are **S** for string and **I** for integer. +The "Use" values are **MT** for mesh topology variables, **LIS** for location index set variables, **D** for data variables, **Do** for domain variables, and **Con** for connectivity index variables. [[table-mesh-topology-attributes]] .Mesh topology attributes @@ -22,15 +21,10 @@ Attribute | Use | Description -| **`boundary_condition`** -| D -| D -| Specifies an variable that defines the boundary condition for each boundary identified by the `boundary_node_connectivity` attribute of the mesh topology variable. - | **`boundary_node_connectivity`** | S | MT -| Specifies an index variable identifying the nodes that each boundary element (i.e. the nodes that defin each edge of a face, or the nodes that define each face of a volume). +| Specifies an index variable identifying the nodes that define where boundary condtions have been provided. Not currently recognised by the CF conventions. | **`cf_role`** | S @@ -89,7 +83,7 @@ Attribute | **`location`** | S -| LIS, D, Do +| D, Do, LIS | Specifies the location within the mesh topology at which the variable is defined. | **`location_index_set`** @@ -99,7 +93,7 @@ Attribute | **`mesh`** | S -| LIS, D, Do +| D, Do, LIS | Specifies a variable that defines a mesh topology. | **`node_coordinates`** @@ -109,7 +103,7 @@ Attribute | **`start_index`** | I -| MT +| MT, LIS, Con | Indicates whether 0- or 1-based indexing is used to identify connected geometric elements; connectivity indices are 0-based by default. | **`topology_dimension`** @@ -120,12 +114,12 @@ Attribute | **`volume_coordinates`** | S | MT -| Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. +| Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. Not currently recognised by the CF conventions. | **`volume_dimension`** | I | MT -| Specifies the position of the dimension used to index the faces in the volume connectivity variable. +| Specifies the position of the dimension used to index the faces in the volume connectivity variable. Not currently recognised by the CF conventions. | **`volume_edge_connectivity`** | S @@ -135,20 +129,20 @@ Attribute | **`volume_face_connectivity`** | S | MT -| Specifies an index variable identifying for every volume the indices of its faces. +| Specifies an index variable identifying for every volume the indices of its faces. Not currently recognised by the CF conventions. | **`volume_node_connectivity`** | S | MT -| Specifies an index variable identifying for every volume the indices of its corner nodes. +| Specifies an index variable identifying for every volume the indices of its corner nodes. Not currently recognised by the CF conventions. | **`volume_shape_type`** | S | MT -| Specifies a flag variable that specifies for every volume its shape. +| Specifies a flag variable that specifies for every volume its shape. Not currently recognised by the CF conventions. | **`volume_volume_connectivity`** | S | MT -| Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. +| Specifies an index variable identifying all volumes that share a face with each volume, i.e. are neighbours. Not currently recognised by the CF conventions. |=============== diff --git a/ch01.adoc b/ch01.adoc index 9eb3a0e4..cdc29c48 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -184,9 +184,9 @@ The CF conventions define attributes which enable the description of data proper [[ugrid-conventions, Section 1.6, "UGRID Conventions"]] === UGRID Conventions -These conventions implicitly incorporate the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. +These conventions implicitly incorporate parts of the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. Only version 1.0 of the UGRID conventions is allowed. The UGRID conventions description is referenced from, rather than rewritten into, this document, i.e. the canonical description of how to store mesh topologies is only to be found at <>. -However, a summary with examples can be found in <>, and to reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. +However, a summary indicating which parts of UGRID are excluded can be found in <>, and to reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. The UGRID conventions have their own conformance document, which should be used in conjunction with the CF conformance document when checking the validity of datasets. \ No newline at end of file From 395b9b1006031993c367876e06949a2eba64ae38 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Tue, 12 Sep 2023 22:06:16 +0100 Subject: [PATCH 40/53] dev --- appi.adoc | 18 ++++-- cf-conventions.adoc | 2 +- ch05.adoc | 154 +++++++++++++++++--------------------------- 3 files changed, 74 insertions(+), 100 deletions(-) diff --git a/appi.adoc b/appi.adoc index 2b0eda35..5c0df93c 100644 --- a/appi.adoc +++ b/appi.adoc @@ -402,9 +402,9 @@ There must be a property indicating the spatial dimensionality of the cells. The array values comprise the node identities, and all array elements that refer to the same node must contain the same value, which must differ from any other value in the array. The array spans the domain axis construct and also has a ragged dimension, whose function depends on the spatial dimensionality of the cells. -For point cells, the array's ragged dimension values are composed of the node identity of each cell in the first element, followed in arbitrary order by the identity of each node to which it is connected by a mesh link. +For each point cell, the first element along the ragged dimension contains the node identity of the cell, and the following elements contain in arbitrary order the identities of all the cells to which it is connected by a mesh link. -For edge and face cells, the array's ragged dimension values are the node identities of the boundary vertices of each cell, in the same order that the boundary vertices are stored by the auxiliary coordinate constructs. +For each edge or face cell, the elements along the ragged dimension contain the node identities of the boundary vertices of the cell, in the same order that the boundary vertices are stored by the auxiliary coordinate constructs. Each boundary vertex except the last is connected by a mesh link to the next vertex along the ragged dimension, and the last vertex is connected to the first. When a domain topology construct is present it is considered to be definitive and must be used in preference to the topology implied by inspection of any other constructs, which is not guaranteed to be the same. @@ -425,13 +425,21 @@ UGRID also describes meshes for three-dimensional volume cells that correspond t [[data-model-cell-connectivity]] ==== Cell connectivity construct -A cell connectivity construct defines explicitly how cells arranged in two or three dimensions in real space but indexed by a single domain (discrete) axis are connected. Connectivity can only be provided when the domain axis construct also has a domain topology construct, and two cells can only be connected if they also have a topological relationship. For instance, the connectivity of two-dimensional face cells could be characterised by whether or not they have shared edges, where the edges are defined by connected nodes of the domain topology construct. +A cell connectivity construct defines explicitly how cells arranged in two or three dimensions in real space but indexed by a single domain (discrete) axis are connected. +Connectivity can only be provided when the domain axis construct also has a domain topology construct, and two cells can only be connected if they also have a topological relationship. +For instance, the connectivity of two-dimensional face cells could be characterised by whether or not they have shared edges, where the edges are defined by connected nodes of the domain topology construct. -The cell connectivity construct consists of an array recording the connectivity, and properties to describe the data. There must be a property indicating the condition by which the connectivity is derived from the domain topology. The array spans the domain axis construct with the addition of a ragged dimension that indexes a unique identity for the cell as well as the identities of all other cells to which it is connected. The cell identity must be recorded in the first element of the ragged dimension, otherwise the order is arbitrary. Note that the connectivity array for point cells is, by definition, equivalent to the array of the domain topology construct. +The cell connectivity construct consists of an array recording the connectivity, and properties to describe the data. +There must be a property indicating the condition by which the connectivity is derived from the domain topology. +The array spans the domain axis construct with the addition of a ragged dimension. +For each cell, the first element along the ragged dimension contains the unique identity of the cell, and the following elements contain in arbitrary order the identities of all the other cells to which the cell is connected. +Note that the connectivity array for point cells is, by definition, equivalent to the array of the domain topology construct. When cell connectivity constructs are present they are considered to be definitive and must be used in preference to the connectivities implied by inspection of any other constructs, apart from the domain topology construct, which are not guaranteed to be the same. -In CF-netCDF a cell topology construct can only be provided by a UGRID mesh topology variable. The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "edge_edge_connectivity" variable (for edge cells) or "face_face_connectivity" variable (for face cells). In the direct case, the integer indices contained in the UGRID variable may be used as the cell identities, although the CF data model attaches no significance to the values other than the fact that some values are the same as others. +In CF-netCDF a cell topology construct can only be provided by a UGRID mesh topology variable. +The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "edge_edge_connectivity" variable (for edge cells) or "face_face_connectivity" variable (for face cells). +In the direct case, the integer indices contained in the UGRID variable may be used as the cell identities, although the CF data model attaches no significance to the values other than the fact that some values are the same as others. Restricting the types of connectivity to those implied by the geospatial topology of the cells precludes connectivity derived from any other sources, but is consistent with UGRID encoding within CF-netCDF. diff --git a/cf-conventions.adoc b/cf-conventions.adoc index 0a853f06..d8d72c3e 100644 --- a/cf-conventions.adoc +++ b/cf-conventions.adoc @@ -1,6 +1,6 @@ include::version.adoc[] = NetCDF Climate and Forecast (CF) Metadata Conventions -Brian{nbsp}Eaton; Jonathan{nbsp}Gregory; Bob{nbsp}Drach; Karl{nbsp}Taylor; Steve{nbsp}Hankin; Jon{nbsp}Blower; John{nbsp}Caron; Rich{nbsp}Signell; Phil{nbsp}Bentley; Greg{nbsp}Rappa; Heinke{nbsp}Höck; Alison{nbsp}Pamment; Martin{nbsp}Juckes; Martin{nbsp}Raspaud; Randy{nbsp}Horne; Timothy{nbsp}Whiteaker; David{nbsp}Blodgett; Charlie{nbsp}Zender; Daniel{nbsp}Lee; David{nbsp}Hassell; Alan{nbsp}D.{nbsp}Snow; Tobias{nbsp}Kölling; Dave{nbsp}Allured; Aleksandar{nbsp}Jelenak; Anders{nbsp}Meier{nbsp}Soerensen; Lucile{nbsp}Gaultier; Sylvain{nbsp}Herlédan; Fernando{nbsp}Manzano; Lars{nbsp}Bärring +Brian{nbsp}Eaton; Jonathan{nbsp}Gregory; Bob{nbsp}Drach; Karl{nbsp}Taylor; Steve{nbsp}Hankin; Jon{nbsp}Blower; John{nbsp}Caron; Rich{nbsp}Signell; Phil{nbsp}Bentley; Greg{nbsp}Rappa; Heinke{nbsp}Höck; Alison{nbsp}Pamment; Martin{nbsp}Juckes; Martin{nbsp}Raspaud; Randy{nbsp}Horne; Timothy{nbsp}Whiteaker; David{nbsp}Blodgett; Charlie{nbsp}Zender; Daniel{nbsp}Lee; David{nbsp}Hassell; Alan{nbsp}D.{nbsp}Snow; Tobias{nbsp}Kölling; Dave{nbsp}Allured; Aleksandar{nbsp}Jelenak; Anders{nbsp}Meier{nbsp}Soerensen; Lucile{nbsp}Gaultier; Sylvain{nbsp}Herlédan; Fernando{nbsp}Manzano; Lars{nbsp}Bärring; Chris{nbsp}Barker Version {current-version}, 31 August, 2022 :doctype: book :pdf-folio-placement: physical diff --git a/ch05.adoc b/ch05.adoc index af83cea4..a8cf697c 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1024,117 +1024,83 @@ In this example the data variables **`humidity`** and **`temp`** from the <>). +A __mesh topology variable__ defines the geospatial topology of cells arranged in two or three dimensions in real space but indexed by a single dimension. +It explicitly describes the topological relationships between cells, i.e. spatial relationships which do not depend on the cell locations. +The cells and their connectivity are defined by a mesh of connected nodes. +A mesh topology variable may provide the topology for one or more domains, defined at the nodes, edges, or faces of the mesh. See the CF data model <> and <> descriptions for more details. -A __location index set variable__ defines a subset of locations of a mesh topology variable, e.g. only boundary points or special locations like weirs and gates. -It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable (see example <>). +The canonical definitions of mesh topology variables and location index set variables are given externally by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. +Some features of by the UGRID conventions <> are not currently allowed in the CF conventions: mesh topology volume cells (that are used to describe fully three-dimensional unstructured mesh topologies); and the "boundary node connectivity" variable (that specifies an index variable identifying the nodes that define where boundary condtions have been provided). -When a data variable's domain is defined by a mesh topology variable it is possible to provide, at selected domain locations, the boundary conditions which constrain the data. +A data or domain variable may use one of a mesh topology variable's domains by referencing the mesh topology variable with the **`mesh`** attribute; along with the identity of required domain provided by the **`location`** attribute (see example <>). -The canonical definitions of mesh topology variables, location index set variables and boundary condition variables are given by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. +The coordinate and bounds values for cells indexed by the mesh topology are defined by the mesh topology variable, but may also be provided by the data or domain variable's **`coordinates`** attribute. +Note that the mesh topology variable allows cell bounds to be provided indpendently of any cell coordinate values because the mesh's __node coordinate variables__, that provide the location of each unique node, can always be mapped to cell vertices. + +A __location index set variable__ defines a subset of locations of a mesh topology variable, e.g. only special locations like weirs and gates. +It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable. [[example-mesh-topology-variable]] [caption="Example 5.21. "] -.Triangular mesh topology variable +.A two-dimensional mesh topology for data stored at trianglur faces, edges and nodes, and with all optional mesh topology varable attributes omitted. ==== ---- dimensions: - nMesh2_node = 4 ; // nNodes - nMesh2_edge = 5 ; // nEdges - nMesh2_face = 2 ; // nFaces - + node = 4 ; // Number of mesh nodes + edge = 5 ; // Number of mesh edges + face = 2 ; // Number of mesh faces + two = 2 ; // Number of nodes per edge + three = 3 ; // Maximum number of nodes per face + time = 12 ; + variables: // Mesh topology variable - integer Mesh2 ; - Mesh2:cf_role = "mesh_topology" ; - Mesh2:long_name = "Topology data of 2D unstructured mesh" ; - Mesh2:topology_dimension = 2 ; - Mesh2:node_coordinates = "Mesh2_node_x Mesh2_node_y" ; - Mesh2:face_node_connectivity = "Mesh2_face_nodes" ; - Mesh2:face_dimension = "nMesh2_face" ; - Mesh2:edge_node_connectivity = "Mesh2_edge_nodes" ; - Mesh2:edge_dimension = "nMesh2_edge" ; - Mesh2:edge_coordinates = "Mesh2_edge_x Mesh2_edge_y" ; - Mesh2:face_coordinates = "Mesh2_face_x Mesh2_face_y" ; - Mesh2:face_edge_connectivity = "Mesh2_face_edges" ; - Mesh2:face_face_connectivity = "Mesh2_face_links" ; - Mesh2:edge_face_connectivity = "Mesh2_edge_face_links" ; - - // Connectivity variables - integer Mesh2_face_nodes(nMesh2_face, Three) ; - Mesh2_face_nodes:long_name = "Maps every triangular face to its three corner nodes." ; - integer Mesh2_edge_nodes(nMesh2_edge, Two) ; - Mesh2_edge_nodes:cf_role = "edge_node_connectivity" ; - Mesh2_edge_nodes:long_name = "Maps every edge to the two nodes that it connects." ; - integer Mesh2_face_edges(nMesh2_face, Three) ; - Mesh2_face_edges:cf_role = "face_edge_connectivity" ; - Mesh2_face_edges:long_name = "Maps every triangular face to its three edges." ; - integer Mesh2_face_links(nMesh2_face, Three) ; - Mesh2_face_links:cf_role = "face_face_connectivity" ; - Mesh2_face_links:long_name = "neighbor faces for faces" ; - Mesh2_face_links:_FillValue = -999 ; - Mesh2_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; - integer Mesh2_edge_face_links(nMesh2_edge, Two) ; - Mesh2_edge_face_links:cf_role = "edge_face_connectivity" ; - Mesh2_edge_face_links:long_name = "neighbor faces for edges" ; - Mesh2_edge_face_links:_FillValue = -999 ; - Mesh2_edge_face_links:comment = "missing neighbor faces are indicated using _FillValue" ; - - // Data at faces, edges, and nodes - double volume_at_faces(nMesh2_face) ; - volume_at_faces:long_name = "volumes" ; - volume_at_faces:units = "m3" ; - volume_at_faces:mesh = "Mesh2" ; + integer Mesh ; + Mesh:cf_role = "mesh_topology" ; + Mesh:long_name = "Topology of a 2D triangular unstructured mesh" ; + Mesh:topology_dimension = 2 ; + Mesh:node_coordinates = "Mesh_node_x Mesh_node_y" ; + Mesh:edge_node_connectivity = "Mesh_face_nodes" ; + Mesh:face_node_connectivity = "Mesh_edge_nodes" ; + + // Mesh node coordinates + double Mesh2_node_x(node) ; + Mesh_node_x:standard_name = "longitude" ; + Mesh_node_x:units = "degrees_east" ; + double Mesh2_node_y(node) ; + Mesh_node_y:standard_name = "latitude" ; + Mesh_node_y:units = "degrees_north" ; + + // Mesh connectivity variables + integer Mesh_face_nodes(face, three) ; + Mesh_face_nodes:long_name = "Maps each face to its 3 corner nodes" ; + integer Mesh_edge_nodes(edge, two) ; + Mesh_edge_nodes:long_name = "Maps each edge to the 2 nodes it connects" ; + + // Coordinate variables + float time(time) ; + time:standard_name = "time" ; + time:units = "days since 2000-01-01" ; + + // Data at mesh faces + double volume_at_faces(time, face) ; + volume_at_faces:standard_name = "air_density" ; + volume_at_faces:units = "kg m-3" ; + volume_at_faces:mesh = "Mesh" ; volume_at_faces:location = "face" ; - volume_at_faces:coordinates = "Mesh2_face_x Mesh2_face_y" ; - double flux_at_edges(nMesh2_edge) ; - fluxe_at_edges:long_name = "flux across edge" ; - fluxe_at_edges:units = "m3 s-1" ; - fluxe_at_edges:mesh = "Mesh2" + // Data at mesh edges + double flux_at_edges(time, edge) ; + fluxe_at_edges:standard_name = "northward_wind" ; + fluxe_at_edges:units = "m s-1" ; + fluxe_at_edges:mesh = "Mesh" fluxe_at_edges:location = "edge" ; - fluxe_at_edges:coordinates = "Mesh2_edge_x Mesh2_edge_y" ; - double height_at_nodes(nMesh2_node) ; + // Data at mesh nodes + double height_at_nodes(time, node) ; height_at_nodes:standard_name = "sea_surface_height_above_geoid" ; height_at_nodes:units = "m" ; - height_at_nodes:mesh = "Mesh2" ; + height_at_nodes:mesh = "Mesh" ; height_at_nodes:location = "node" ; - height_at_nodes:coordinates = "Mesh2_node_x Mesh2_node_y" ; ---- -This example shows a mesh topology variable that defines a 2D triangular mesh topology comprising three domains: one at the triangular element nodes, one along the triangular element edges, and one on the triangular faces. -Each data variable selects exactly one of these for its domain. -The auxiliary coordinate variables identified by the **`node_coordinates`**, **`edge_coordinates`**, and **`face_coordinates`** mesh topology variable attributes have been omitted from the CDL for clarity. - -==== - -[[example-location-index-set-variable]] -[caption="Example 5.22. "] -.Location index set variable -==== ----- -dimensions: - time = 12 ; - nMesh2_set = 2 ; - -variables: - // Location index set variable - integer Mesh2_set(nMesh2_set) ; - Mesh2_set:cf_role = "location_index_set" ; - Mesh2_set:long_name = "Defines Mesh2_set as subset of the nodes of Mesh2."; - Mesh2_set:mesh = "Mesh2" ; - Mesh2_set:location = "node" ; - - // Data at a subset of the nodes of Mesh2 - double Mesh2_waterlevel(time, nMesh2_set) ; - Mesh2_waterlevel:standard_name = "sea_surface_height_above_geoid" ; - Mesh2_waterlevel:units = "m" ; - Mesh2_waterlevel:location_index_set = "Mesh2_set" ; ----- - -This example shows a domain defined by a location index set variable. -The mesh topology variable `Mesh2`, not shown but as defined in example <>, has four nodes, two of which are used here to define the new domain in `Mesh2_set`. - ==== From 41ca312b3c3fdf20386df64083ac04b554abf606 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Wed, 13 Sep 2023 16:19:48 +0100 Subject: [PATCH 41/53] dev --- appi.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appi.adoc b/appi.adoc index 5c0df93c..70235071 100644 --- a/appi.adoc +++ b/appi.adoc @@ -438,7 +438,7 @@ Note that the connectivity array for point cells is, by definition, equivalent t When cell connectivity constructs are present they are considered to be definitive and must be used in preference to the connectivities implied by inspection of any other constructs, apart from the domain topology construct, which are not guaranteed to be the same. In CF-netCDF a cell topology construct can only be provided by a UGRID mesh topology variable. -The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "edge_edge_connectivity" variable (for edge cells) or "face_face_connectivity" variable (for face cells). +The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "face_face_connectivity" variable (for face cells). In the direct case, the integer indices contained in the UGRID variable may be used as the cell identities, although the CF data model attaches no significance to the values other than the fact that some values are the same as others. Restricting the types of connectivity to those implied by the geospatial topology of the cells precludes connectivity derived from any other sources, but is consistent with UGRID encoding within CF-netCDF. From 78cecee5cf7244ed2c9a0c63f4de615a0bf9ed9c Mon Sep 17 00:00:00 2001 From: David Hassell Date: Fri, 15 Sep 2023 10:42:29 +0100 Subject: [PATCH 42/53] dev --- ch01.adoc | 3 ++- ch05.adoc | 3 +-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ch01.adoc b/ch01.adoc index b9ffc3ac..6b854f07 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -235,6 +235,7 @@ Briefly the new attributes allow: These conventions implicitly incorporate parts of the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. Only version 1.0 of the UGRID conventions is allowed. The UGRID conventions description is referenced from, rather than rewritten into, this document, i.e. the canonical description of how to store mesh topologies is only to be found at <>. -However, a summary indicating which parts of UGRID are excluded can be found in <>, and to reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. +However, a summary indicating how UGRID related to other parts of the CF conventions, and which features of UGRID are excluded from CF, can be found in <>. +To reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. The UGRID conventions have their own conformance document, which should be used in conjunction with the CF conformance document when checking the validity of datasets. \ No newline at end of file diff --git a/ch05.adoc b/ch05.adoc index a8cf697c..e704bce2 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1025,8 +1025,7 @@ In this example the data variables **`humidity`** and **`temp`** from the <> and <> descriptions for more details. The canonical definitions of mesh topology variables and location index set variables are given externally by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. From 416e8d8c58cae520aee1a406524080c0bdf4c4cf Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 21 Sep 2023 15:03:03 +0100 Subject: [PATCH 43/53] Mesh topology figure --- images/mesh_figure.svg | 134 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 images/mesh_figure.svg diff --git a/images/mesh_figure.svg b/images/mesh_figure.svg new file mode 100644 index 00000000..0552a590 --- /dev/null +++ b/images/mesh_figure.svg @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file From 7ac449a9b50ba46e696c19294237f7bf691d5961 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 21 Sep 2023 15:03:14 +0100 Subject: [PATCH 44/53] UGRID text --- appi.adoc | 2 +- appk.adoc | 14 +++++----- cf-conventions.adoc | 4 +++ ch01.adoc | 4 +-- ch05.adoc | 64 ++++++++++++++++++++++++--------------------- 5 files changed, 48 insertions(+), 40 deletions(-) diff --git a/appi.adoc b/appi.adoc index 70235071..b1b60682 100644 --- a/appi.adoc +++ b/appi.adoc @@ -393,7 +393,7 @@ For edge and face cells, every node corresponds to a boundary vertex of a cell; [caption="Figure {doc-part}.{counter:figure}. ", reftext=Figure {doc-part}.{figure}] [.text-center] .A topology defined by a mesh with five nodes and six links. -image::images/cfdm_mixed_mesh.png[,100%,pdfwidth=50vw,align="center"] +image::images/mesh_figure.svg[,100%,pdfwidth=25vw,align="center"] For example, the mesh depicted in <> may be used with any of three domain topology constructs for domains comprising two face cells (one triangle and one quadrilateral), six edge cells, and five point cells respectively. diff --git a/appk.adoc b/appk.adoc index 15a455ed..43866b0b 100644 --- a/appk.adoc +++ b/appk.adoc @@ -42,9 +42,9 @@ Attribute | Specifies the auxiliary coordinate variables associated with the characteristic location of the edges (commonly the midpoint). | **`edge_dimension`** -| I +| S | MT -| Specifies the position of the dimension used to index the nodes in the edge connectivity variable. +| Specifies the dimension used to index the nodes in the edge connectivity variable. | **`edge_face_connectivity`** | S @@ -62,9 +62,9 @@ Attribute | Specifies the auxiliary coordinate variables associated with the characteristic location of faces. | **`face_dimension`** -| I +| S | MT -| Specifies the position of the dimension used to index the edges in the face connectivity variable. +| Specifies the dimension used to index the edges in the face connectivity variable. | **`face_edge_connectivity`** | S @@ -103,7 +103,7 @@ Attribute | **`start_index`** | I -| MT, LIS, Con +| LIS, Con | Indicates whether 0- or 1-based indexing is used to identify connected geometric elements; connectivity indices are 0-based by default. | **`topology_dimension`** @@ -117,9 +117,9 @@ Attribute | Specifies the auxiliary coordinate variables associated with the characteristic location of volumes. Not currently recognised by the CF conventions. | **`volume_dimension`** -| I +| S | MT -| Specifies the position of the dimension used to index the faces in the volume connectivity variable. Not currently recognised by the CF conventions. +| Specifies the dimension used to index the faces in the volume connectivity variable. Not currently recognised by the CF conventions. | **`volume_edge_connectivity`** | S diff --git a/cf-conventions.adoc b/cf-conventions.adoc index d8d72c3e..fd721256 100644 --- a/cf-conventions.adoc +++ b/cf-conventions.adoc @@ -47,6 +47,7 @@ include::toc-extra.adoc[] * Sylvain Herlédan, OceanDataLab * Fernando Manzano, Puertos del Estado * Lars Bärring, SMHI +* Chris Barker, NOAA Many others have contributed to the development of CF through their participation in discussions about proposed changes. @@ -122,6 +123,9 @@ include::appi.adoc[] :numbered!: include::appj.adoc[] +:numbered!: +include::appk.adoc[] + :numbered!: include::history.adoc[] diff --git a/ch01.adoc b/ch01.adoc index 6b854f07..f1ce0c95 100644 --- a/ch01.adoc +++ b/ch01.adoc @@ -234,8 +234,8 @@ Briefly the new attributes allow: These conventions implicitly incorporate parts of the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files using mesh topologies <>. Only version 1.0 of the UGRID conventions is allowed. -The UGRID conventions description is referenced from, rather than rewritten into, this document, i.e. the canonical description of how to store mesh topologies is only to be found at <>. -However, a summary indicating how UGRID related to other parts of the CF conventions, and which features of UGRID are excluded from CF, can be found in <>. +The UGRID conventions description is referenced from, rather than rewritten into, this document and the canonical description of how to store mesh topologies is only to be found at <>. +A summary indicating how UGRID relates to other parts of the CF conventions, and which features of UGRID are excluded from CF, can be found in <>. To reduce the chance of ambiguities arising from their accidental re-use, all of the UGRID standardized attributes are specified in <> and <>. The UGRID conventions have their own conformance document, which should be used in conjunction with the CF conformance document when checking the validity of datasets. \ No newline at end of file diff --git a/ch05.adoc b/ch05.adoc index e704bce2..24f185b2 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1025,81 +1025,85 @@ In this example the data variables **`humidity`** and **`temp`** from the <> and <> descriptions for more details. +It explicitly describes the topological relationships between cells, i.e. spatial relationships which do not depend on the cell locations, via a mesh of connected nodes. +A mesh topology variable may provide the topology for one or more domains, defined at the nodes, edges, or faces of the mesh. +See the <> and <> descriptions in the CF data model for more details, including on how the mesh relates to the cells of the domain. The canonical definitions of mesh topology variables and location index set variables are given externally by the UGRID conventions <>, but their standardized attributes, many of which are optional, are listed in <> and <>. -Some features of by the UGRID conventions <> are not currently allowed in the CF conventions: mesh topology volume cells (that are used to describe fully three-dimensional unstructured mesh topologies); and the "boundary node connectivity" variable (that specifies an index variable identifying the nodes that define where boundary condtions have been provided). +Some features of the UGRID conventions <> are not currently recognized by the CF conventions: mesh topology volume cells (that are used to describe fully three-dimensional unstructured mesh topologies); and the "boundary node connectivity" variable (that specifies an index variable identifying the nodes that define where boundary condtions have been provided). A data or domain variable may use one of a mesh topology variable's domains by referencing the mesh topology variable with the **`mesh`** attribute; along with the identity of required domain provided by the **`location`** attribute (see example <>). -The coordinate and bounds values for cells indexed by the mesh topology are defined by the mesh topology variable, but may also be provided by the data or domain variable's **`coordinates`** attribute. -Note that the mesh topology variable allows cell bounds to be provided indpendently of any cell coordinate values because the mesh's __node coordinate variables__, that provide the location of each unique node, can always be mapped to cell vertices. +The variables containing the coordinate values for cells indexed by the mesh topology are defined by the mesh topology variable but are equivalent to one-dimensional auxiliary coordinate variables, and so may also be provided by the data or domain variable's **`coordinates`** attribute. +Note that the mesh topology variable allows cell bounds to be provided without any cell coordinate values, via its __**`node_coordinates`**__ attribute. A __location index set variable__ defines a subset of locations of a mesh topology variable, e.g. only special locations like weirs and gates. It is provided as a space saving device to prevent the need to redefine parts of an existing mesh topology variable, and as such is logically equivalent to a mesh topology variable. +A data or domain variable references a location index set variable via its **`location_index_set`** attribute. [[example-mesh-topology-variable]] [caption="Example 5.21. "] -.A two-dimensional mesh topology for data stored at trianglur faces, edges and nodes, and with all optional mesh topology varable attributes omitted. +.A two-dimensional UGRID mesh topology variable ==== ---- dimensions: - node = 4 ; // Number of mesh nodes - edge = 5 ; // Number of mesh edges + node = 5 ; // Number of mesh nodes + edge = 6 ; // Number of mesh edges face = 2 ; // Number of mesh faces two = 2 ; // Number of nodes per edge - three = 3 ; // Maximum number of nodes per face + four = 4 ; // Maximum number of nodes per face time = 12 ; variables: // Mesh topology variable - integer Mesh ; - Mesh:cf_role = "mesh_topology" ; - Mesh:long_name = "Topology of a 2D triangular unstructured mesh" ; - Mesh:topology_dimension = 2 ; - Mesh:node_coordinates = "Mesh_node_x Mesh_node_y" ; - Mesh:edge_node_connectivity = "Mesh_face_nodes" ; - Mesh:face_node_connectivity = "Mesh_edge_nodes" ; + integer mesh ; + mesh:cf_role = "mesh_topology" ; + mesh:long_name = "Topology of a 2-d unstructured mesh" ; + mesh:topology_dimension = 2 ; + mesh:node_coordinates = "mesh_node_x mesh_node_y" ; + mesh:edge_node_connectivity = "mesh_edge_nodes" ; + mesh:face_node_connectivity = "mesh_face_nodes" ; // Mesh node coordinates - double Mesh2_node_x(node) ; - Mesh_node_x:standard_name = "longitude" ; - Mesh_node_x:units = "degrees_east" ; - double Mesh2_node_y(node) ; - Mesh_node_y:standard_name = "latitude" ; - Mesh_node_y:units = "degrees_north" ; + double mesh2_node_x(node) ; + mesh_node_x:standard_name = "longitude" ; + mesh_node_x:units = "degrees_east" ; + double mesh2_node_y(node) ; + mesh_node_y:standard_name = "latitude" ; + mesh_node_y:units = "degrees_north" ; // Mesh connectivity variables - integer Mesh_face_nodes(face, three) ; - Mesh_face_nodes:long_name = "Maps each face to its 3 corner nodes" ; - integer Mesh_edge_nodes(edge, two) ; - Mesh_edge_nodes:long_name = "Maps each edge to the 2 nodes it connects" ; + integer mesh_face_nodes(face, four) ; + mesh_face_nodes:long_name = "Maps each face to its 3 or 4 corner nodes" ; + integer mesh_edge_nodes(edge, two) ; + mesh_edge_nodes:long_name = "Maps each edge to the 2 nodes it connects" ; // Coordinate variables float time(time) ; time:standard_name = "time" ; - time:units = "days since 2000-01-01" ; + time:units = "days since 2004-06-01" ; // Data at mesh faces double volume_at_faces(time, face) ; volume_at_faces:standard_name = "air_density" ; volume_at_faces:units = "kg m-3" ; - volume_at_faces:mesh = "Mesh" ; + volume_at_faces:mesh = "mesh" ; volume_at_faces:location = "face" ; // Data at mesh edges double flux_at_edges(time, edge) ; fluxe_at_edges:standard_name = "northward_wind" ; fluxe_at_edges:units = "m s-1" ; - fluxe_at_edges:mesh = "Mesh" + fluxe_at_edges:mesh = "mesh" fluxe_at_edges:location = "edge" ; // Data at mesh nodes double height_at_nodes(time, node) ; height_at_nodes:standard_name = "sea_surface_height_above_geoid" ; height_at_nodes:units = "m" ; - height_at_nodes:mesh = "Mesh" ; + height_at_nodes:mesh = "mesh" ; height_at_nodes:location = "node" ; ---- +A two-dimensional UGRID mesh topology variable for the mesh depicted in <>, with data variables defined at face, edge and node elements of the mesh. All optional attributes have been omitted. + ==== From d808321999b75d4dff36f2bdb5af2642a865fcb4 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 21 Sep 2023 15:18:14 +0100 Subject: [PATCH 45/53] dev --- appd.adoc | 2 +- ch05.adoc | 6 +++--- conformance.adoc | 7 ++----- toc-extra.adoc | 1 + 4 files changed, 7 insertions(+), 9 deletions(-) diff --git a/appd.adoc b/appd.adoc index 66c0ddc1..a2e77cc2 100644 --- a/appd.adoc +++ b/appd.adoc @@ -431,7 +431,7 @@ No `standard_name` has been defined for `z1`, `z2`, `a`, `href` or `k_c`. // But AsciiDoctor will wrap an image title, so assign the title to a 1-pixel transparent image, // and put the table immediately thereafter, with its own title: [[table-computed-standard-names]] -.Consistent sets of values for the standard_names of formula terms and the computed_standard_name needed in defining the ocean sigma coordinate, the ocean s-coordinate, the ocean_sigma over z coordinate, and the ocean double sigma coordinate. +.Consistent sets of values for the standard_names of formula terms and the computed_standard_name needed in defining the ocean sigma coordinate, the ocean s-coordinate, the ocean_sigma over z coordinate, and the ocean double sigma coordinate. image::NFFFFFF-1.0.png[caption=""] [options="header",cols="1,3,2,3",caption="Table D.1. "] diff --git a/ch05.adoc b/ch05.adoc index 24f185b2..13a9d216 100644 --- a/ch05.adoc +++ b/ch05.adoc @@ -1049,9 +1049,9 @@ A data or domain variable references a location index set variable via its **`lo dimensions: node = 5 ; // Number of mesh nodes edge = 6 ; // Number of mesh edges - face = 2 ; // Number of mesh faces + face = 2 ; // Number of mesh faces two = 2 ; // Number of nodes per edge - four = 4 ; // Maximum number of nodes per face + four = 4 ; // Maximum number of nodes per face time = 12 ; variables: @@ -1081,7 +1081,7 @@ variables: // Coordinate variables float time(time) ; time:standard_name = "time" ; - time:units = "days since 2004-06-01" ; + time:units = "days since 2004-06-01" ; // Data at mesh faces double volume_at_faces(time, face) ; diff --git a/conformance.adoc b/conformance.adoc index 72e1b2a9..d158a911 100644 --- a/conformance.adoc +++ b/conformance.adoc @@ -11,11 +11,8 @@ If there are any discrepencies between the two, the conventions document is the === UGRID Conventions -Requirements and recommendations relating to the UGRID conventions for -storing unstructured (or flexible mesh) data in netCDF files are not -described here, but are nonetheless considered as part of the CF -conformance requirements and recommendations. See <> -for the UGRID conformance requirements and recommendations. +Requirements and recommendations relating to the UGRID conventions for storing unstructured (or flexible mesh) data in netCDF files are not described here, but are nonetheless considered as part of the CF conformance requirements and recommendations. +See https://github.com/ugrid-conventions/ugrid-conventions for the UGRID conformance requirements and recommendations. [[filename]] === 2.1 Filename diff --git a/toc-extra.adoc b/toc-extra.adoc index f74ba8ff..c2f3e256 100644 --- a/toc-extra.adoc +++ b/toc-extra.adoc @@ -48,6 +48,7 @@ K.2. <> 5.18. <> 5.19. <> 5.20. <> +5.21. <> 6.1. <> 6.1.2. <> 6.2. <> From d075264385fdbcfb05c0b79b891bbcbaa4fdd687 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 21 Sep 2023 15:36:28 +0100 Subject: [PATCH 46/53] UGRID --- history.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/history.adoc b/history.adoc index 0e60b0a0..f6578121 100644 --- a/history.adoc +++ b/history.adoc @@ -22,6 +22,7 @@ * {pull-requests}408[Pull request #408]: Deleted a sentence on "rotated Mercator" under `Oblique Mercator` grid mapping in Appendix F * {issues}260[Issue #260]: Clarify use of dimensionless units * {issues}410[Issue #410]: Delete "on a spherical Earth" from the definition of the `latitude_longitude` grid mapping in Appendix F +* {issues}153[Issue #153]: Reference UGRID conventions in CF === Version 1.10 (31 August 2022) From 7944dee8acf3440c9feda2800dae7e8112d19df6 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Tue, 26 Sep 2023 00:14:13 +0100 Subject: [PATCH 47/53] new data model figure for meshes --- images/cfdm_field.gv | 172 ++++++------- images/cfdm_field.svg | 557 +++++++++++++++++++++--------------------- 2 files changed, 364 insertions(+), 365 deletions(-) diff --git a/images/cfdm_field.gv b/images/cfdm_field.gv index 6b1cd1ad..9938c518 100644 --- a/images/cfdm_field.gv +++ b/images/cfdm_field.gv @@ -17,62 +17,62 @@ node [ fontname="Arial" ] -# -------------------------------------------------------------------- -# CF-netCDF variables -# -------------------------------------------------------------------- -DomainVariable [ - fillcolor="#C3FFFF" - label="CN::Domain\nVariable" - ] -DataVariable [ - fillcolor="#C3FFFF" - label="CN::Data\nVariable" - ] - # -------------------------------------------------------------------- # CF data model constructs # -------------------------------------------------------------------- Domain [ label="<>\nDomain" - width=2.5 + width=2 height=1 ] Field [ label="<>\nField" + width=2.5 height=1 ] CellMethod [ label="<>\nCellMethod" + width=2 ] DomainAxis [ label="<>\nDomainAxis" + width=2 ] DomainAncillary [ label="<>\nDomainAncillary" + width=2 ] CellMeasure [ label="<>\nCellMeasure" + width=2 ] CoordinateReference [ label="<>\nCoordinateReference " - width=2.75 + width=2 ] - label="<>\nCoordinateReference " - ] AuxiliaryCoordinate [ label="<>\nAuxillaryCoordinate" + width=2 ] DimensionCoordinate [ label="<>\nDimensionCoordinate" + width=2 ] FieldAncillary [ label="<>\nFieldAncillary" + width=2 ] DomainTopology [ label="<>\nDomainTopology" + width=2 + ] +CellConnectivity [ + label="<>\nCellConnectivity" + width=2 ] GenericCoordinate [ label="<>\nGeneric\nCoordinate\nConstruct" + width=2 fillcolor=white ] @@ -100,79 +100,87 @@ route11 route12 route13 -DataVariable -> Field [dir=back arrowtail=vee weight=100] - -Field -> route8 [arrowtail=odiamond arrowhead=none dir=both weight=100] -route8 -> Domain [arrowtail=none arrowhead=vee dir=bothhead - headlabel="0..1 " weight=100 labelfontsize=11.0 weight=100] -route1 -> Field [arrowhead=diamond] -Field -> route2 [arrowtail=diamond arrowhead=none dir=both] -{rank=same; route1, Field, route2} - -edge [arrowtail=vee - arrowhead=diamond - dir=both +edge [dir=both arrowsize=1.0 fontname="Arial" labelfontsize=11.0 ] -Domain -> route11 [arrowtail=diamond arrowhead=none weight=100] -route11 -> GenericCoordinate [arrowhead=vee arrowtail=none headlabel="0..* " weight=100] -route2 -> CellMethod [arrowhead=vee arrowtail=none headlabel="0..* " - weight=100] -route1 -> FieldAncillary [arrowhead=vee arrowtail=none headlabel="0..* " - weight=100] -Domain -> DomainAxis [arrowtail=vee arrowhead=diamond taillabel="0..* "] -{rank=same; Domain, DomainAxis} - -route6 -> Domain [arrowtail=none] -{rank=same;route6, Domain} -route6 -> CoordinateReference [arrowtail=none arrowhead=vee headlabel="0..* "] - -Domain -> route7 [arrowtail=diamond arrowhead=none] -route7-> CellMeasure [headlabel="0..* " arrowhead=vee arrowtail=none] -Domain -> DomainAncillary [headlabel="0..* " arrowhead=vee arrowtail=diamond] -FieldAncillary -> Domain [label="uses \nparent " - arrowhead=vee arrowtail=none labelfontsize=11.0] - -{rank=same; DomainVariable, DataVariable} - -route9 -> Domain [dir=none] -DomainVariable -> route9 [arrowtail=vee, arrowhead=none, weight=100] -{rank=same; route1, route9} - - -Domain -> DomainTopology [taillabel="0..* " weight=100] - -GenericCoordinate -> route4 [arrowhead=none arrowtail=empty weight=100] -route4 -> AuxiliaryCoordinate [dir=none weight=100] -{rank=same; route4, AuxiliaryCoordinate} -route4 -> route5 [dir=none weight=100] -route5 -> DimensionCoordinate [dir=none weight=100] -{rank=same; route5, DimensionCoordinate} -{rank=same;DomainAncillary, GenericCoordinate, route7, CellMeasure} - -DomainAncillary -> CoordinateReference [arrowhead=none, arrowtail=vee - taillabel="0..* " - labeldistance=1.1 - weight=100] - -CellMethod -> DomainAxis [taillabel="1..* " weight=100] -GenericCoordinate -> route3 [arrowhead=none arrowtail=vee - taillabel="0..* " - labeldistance=1.1 - weight=100] -route3 -> CoordinateReference [dir=none] -{rank=same; CoordinateReference, DimensionCoordinate} +Field -> route1 [arrowtail=odiamond arrowhead=none weight=100] +Field -> route2 [arrowtail=diamond arrowhead=none weight=100] +route2 -> FieldAncillary [arrowhead=vee arrowtail=none + headlabel="0..* " + weight=100 minlen=7] +{rank=same; route1, route2, FieldAncillary} +#----------------------------- +route1 -> route3 [arrowtail=none arrowhead=none weight=100] +route2 -> route4 [arrowtail=none arrowhead=none weight=100] +route4 -> CellMethod [arrowhead=vee arrowtail=none + headlabel="0..* " + weight=100 minlen=7] +{rank=same; route3, route4, CellMethod} +#----------------------------- +route3 -> Domain [arrowtail=none arrowhead=vee + headlabel="0..1 " weight=100] +Domain -> route5 [arrowtail=diamond arrowhead=none + weight=100 labelfontsize=11.0 minlen=2] +route5 -> DomainAxis [arrowtail=none arrowhead=vee + headlabel="0..* " weight=100 minlen=3] +route6 -> DimensionCoordinate [arrowtail=none arrowhead=none + weight=100 minlen=2] +CellMethod -> DomainAxis [arrowtail=none arrowhead=vee + headlabel="0..* " weight=100] +{rank=same; Domain, route5, DomainAxis, route6, DimensionCoordinate} +#----------------------------- +route5 -> route7 [arrowhead=none arrowtail=none weight=100] +route6 -> route8 [arrowtail=none arrowhead=none weight=100] +route7 -> GenericCoordinate [arrowtail=none arrowhead=vee + headlabel="0..* " weight=100 minlen=3] +GenericCoordinate -> route8 [arrowtail=empty arrowhead=none + weight=100 minlen=2] +route8 -> AuxiliaryCoordinate [arrowtail=none arrowhead=none minlen=2] +{rank=same; route7, GenericCoordinate, route8, AuxiliaryCoordinate} +#----------------------------- +route7 -> route9 [arrowtail=none arrowhead=none weight=100] +route9 -> CoordinateReference[arrowtail=none arrowhead=vee + headlabel="0..* " weight=100 minlen=3] +GenericCoordinate -> CoordinateReference [arrowtail=vee arrowhead=none + taillabel="0..* " weight=100] +{rank=same; route9, CoordinateReference} +#----------------------------- +route9 -> route10 [arrowtail=none arrowhead=none weight=100] +route10 -> DomainAncillary [arrowtail=none arrowhead=vee + weight=100 headlabel="0..* " minlen=3] +CoordinateReference -> DomainAncillary [arrowtail=none arrowhead=vee + headlabel="0..* " weight=100] +{rank=same; route10, DomainAncillary} +#----------------------------- +route10 -> route11 [arrowtail=none arrowhead=none weight=100] +route11 -> CellMeasure [arrowtail=none arrowhead=vee + weight=100 headlabel="0..* " minlen=3] +{rank=same; route11, CellMeasure} +#----------------------------- +route11 -> route12 [arrowtail=none arrowhead=none weight=100] +route12 -> DomainTopology [arrowtail=none arrowhead=vee weight=100 + headlabel="0..* " minlen=3] +{rank=same; route12, DomainTopology} +#----------------------------- +route12 -> route13 [arrowtail=none arrowhead=none weight=100] +route13 -> CellConnectivity [arrowtail=none arrowhead=vee weight=100 + headlabel="0..* " minlen=3] +{rank=same; route13, CellConnectivity} +#----------------------------- # -------------------------------------------------------------------- # Invisible edges used to aid in layout # -------------------------------------------------------------------- -DomainAxis -> AuxiliaryCoordinate [style=invis] -DomainAxis -> CellMeasure [style=invis weight=100] -CellMeasure -> AuxiliaryCoordinate [style=invis weight=100] -AuxiliaryCoordinate -> DimensionCoordinate[style=invis weight=100] -DomainVariable -> FieldAncillary [style=invis weight=100] -route9 -> route1 [style=invis weight=100] +route1 -> route2 [style=invis weight=100 minlen=3] +route3 -> route4 [style=invis weight=100 minlen=3] +FieldAncillary -> CellMethod [style=invis weight=100] +DomainAxis -> route6 [style=invis weight=100 minlen=2] +DomainAxis -> GenericCoordinate [style=invis weight=100] +DimensionCoordinate -> AuxiliaryCoordinate [style=invis weight=100] +DomainAncillary -> CellMeasure [style=invis weight=100] +CellMeasure -> DomainTopology [style=invis weight=100] +DomainTopology -> CellConnectivity [style=invis weight=100] } diff --git a/images/cfdm_field.svg b/images/cfdm_field.svg index 2e658775..f7d2ee27 100644 --- a/images/cfdm_field.svg +++ b/images/cfdm_field.svg @@ -4,356 +4,347 @@ - - + + %3 - - + + -DomainVariable - -CN::Domain -Variable - - - -FieldAncillary - -<<construct>> -FieldAncillary - - - - -route9 - +Domain + +<<construct>> +Domain - - -DomainVariable->route9 - - + + +route5 + - - -DataVariable - -CN::Data -Variable + + +Domain->route5 + + - + Field - -<<construct>> -Field - - - -DataVariable->Field - - - - - -Domain - -<<construct>> -Domain - - - -DomainAxis - -<<construct>> -DomainAxis - - - -Domain->DomainAxis - - - -0..*   - - - -DomainAncillary - -<<construct>> -DomainAncillary - - - -Domain->DomainAncillary - - - -0..*   - - - -DomainTopology - -<<construct>> -DomainTopology - - - -Domain->DomainTopology - - - -0..*    - - - -route7 - - - - -Domain->route7 - - + +<<construct>> +Field - - -route11 - + + +route1 + - - -Domain->route11 - - + + +Field->route1 + + - + route2 - + - -Field->route2 - - - - - -route8 - - - -Field->route8 - - +Field->route2 + + - + CellMethod - -<<construct>> -CellMethod + +<<construct>> +CellMethod + + + +DomainAxis + +<<construct>> +DomainAxis - + CellMethod->DomainAxis - - - -1..*   + + +0..*    + + + +GenericCoordinate + +<<abstract>> +Generic +Coordinate +Construct + + + + +route6 + + + + + +DomainAncillary + +<<construct>> +DomainAncillary - + CellMeasure - -<<construct>> -CellMeasure + +<<construct>> +CellMeasure - - - -AuxiliaryCoordinate - -<<construct>> -AuxillaryCoordinate + + + +DomainTopology + +<<construct>> +DomainTopology - + - + CoordinateReference - -<<construct>> -CoordinateReference + +<<construct>> +CoordinateReference - - -DomainAncillary->CoordinateReference - - -0..*       + + +CoordinateReference->DomainAncillary + + +0..*    + + + +AuxiliaryCoordinate + +<<construct>> +AuxillaryCoordinate - - + DimensionCoordinate - -<<construct>> -DimensionCoordinate + +<<construct>> +DimensionCoordinate - - - -FieldAncillary->Domain - - -uses              -parent                + + + +FieldAncillary + +<<construct>> +FieldAncillary - - -GenericCoordinate - -<<abstract>> -Generic -Coordinate -Construct + + + +CellConnectivity + +<<construct>> +CellConnectivity + + + + +GenericCoordinate->CoordinateReference + + +0..*    + + + +route8 + + + +GenericCoordinate->route8 + + + + - + route3 - + - - -GenericCoordinate->route3 - - -0..*       + + +route1->route3 + + + + +route2->FieldAncillary + + +0..*     - + route4 - + - - -GenericCoordinate->route4 - - + + +route2->route4 + - - -route1 - + + +route3->Domain + + +0..1    - - -route1->Field - - + + + +route4->CellMethod + + +0..*     - + -route1->FieldAncillary - - -0..*   +route5->DomainAxis + + +0..*     - - -route2->CellMethod - - -0..*    + + +route7 + - - -route3->CoordinateReference - + + +route5->route7 + - - -route4->AuxiliaryCoordinate - + + +route6->DimensionCoordinate + - - -route5 - + + +route6->route8 + - - -route4->route5 - + + +route7->GenericCoordinate + + +0..*     - - -route5->DimensionCoordinate - + + +route9 + - - -route6 - + + +route7->route9 + - - -route6->Domain - - + + +route8->AuxiliaryCoordinate + - - -route6->CoordinateReference - - -0..*   + + +route9->CoordinateReference + + +0..*     - - -route7->CellMeasure - - -0..*   + + +route10 + - - -route8->Domain - - -0..1   + + +route9->route10 + - - -route9->Domain - + + +route10->DomainAncillary + + +0..*     - - + -route10 - +route11 + - - -route11->GenericCoordinate - - -0..*    + + +route10->route11 + + + + +route11->CellMeasure + + +0..*     - + route12 - + + + + +route11->route12 + + + + +route12->DomainTopology + + +0..*     - + route13 - + + + + +route12->route13 + + + + +route13->CellConnectivity + + +0..*     From 3a9cc8f8a1c49800c8bd89efc222e32c29736afc Mon Sep 17 00:00:00 2001 From: David Hassell Date: Mon, 2 Oct 2023 08:59:17 +0100 Subject: [PATCH 48/53] grammar --- appi.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appi.adoc b/appi.adoc index b1b60682..d8ae19ef 100644 --- a/appi.adoc +++ b/appi.adoc @@ -435,7 +435,7 @@ The array spans the domain axis construct with the addition of a ragged dimensio For each cell, the first element along the ragged dimension contains the unique identity of the cell, and the following elements contain in arbitrary order the identities of all the other cells to which the cell is connected. Note that the connectivity array for point cells is, by definition, equivalent to the array of the domain topology construct. -When cell connectivity constructs are present they are considered to be definitive and must be used in preference to the connectivities implied by inspection of any other constructs, apart from the domain topology construct, which are not guaranteed to be the same. +When cell connectivity constructs are present, they are considered to be definitive and must be used in preference to the connectivities implied by inspection of any other constructs, apart from the domain topology construct, which are not guaranteed to be the same. In CF-netCDF a cell topology construct can only be provided by a UGRID mesh topology variable. The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "face_face_connectivity" variable (for face cells). From 06c97c037120ef4610ef3c9e61c911575ab4f96c Mon Sep 17 00:00:00 2001 From: David Hassell Date: Mon, 2 Oct 2023 09:06:15 +0100 Subject: [PATCH 49/53] mesh coordinates with only bounds --- appi.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appi.adoc b/appi.adoc index d8ae19ef..dff3c856 100644 --- a/appi.adoc +++ b/appi.adoc @@ -266,7 +266,7 @@ If a domain axis construct does not correspond to a continuous physical quantity For example, this is the case for an axis that runs over ocean basins or area types, or for a domain axis that indexes a time series at scattered points. These axes are discrete axes in CF-netCDF. In such cases cells may be described with one-dimensional auxiliary coordinate constructs for which, provided that there is a cell bounds array to describe the cell extents, the coordinate array is optional, since coordinates are not always well defined for such cells. -A CF-netCDF geometry container variable is used to store cell bounds without coordinates for a discrete axis. +A CF-netCDF geometry container variable or mesh topology variable is used to store cell bounds without coordinates for a discrete axis. In CF-netCDF, when a geometry container variable is present it explicitly describes the geometry type and identifies the node coordinate variables that contain the cell vertices. The geometry container variable also identifies a node count variable that contains the number of nodes per cell when more than one cell is present, and a part node count variable that contains the number of nodes per cell part when cells are composed of multipart lines, multipart polygons, or polygons with holes. From 5fb191fc2b8792df3f729e962c854b2e1c3eef85 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Mon, 2 Oct 2023 09:10:21 +0100 Subject: [PATCH 50/53] clarity --- appi.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/appi.adoc b/appi.adoc index dff3c856..6c8767a8 100644 --- a/appi.adoc +++ b/appi.adoc @@ -435,7 +435,9 @@ The array spans the domain axis construct with the addition of a ragged dimensio For each cell, the first element along the ragged dimension contains the unique identity of the cell, and the following elements contain in arbitrary order the identities of all the other cells to which the cell is connected. Note that the connectivity array for point cells is, by definition, equivalent to the array of the domain topology construct. -When cell connectivity constructs are present, they are considered to be definitive and must be used in preference to the connectivities implied by inspection of any other constructs, apart from the domain topology construct, which are not guaranteed to be the same. +When cell connectivity constructs are present, they are considered to define the connectivity of the cells. +Exactly the same connectivity information could be derived from the domain topology construct. +Connectivity information inferred from inspection of any other constructs is not guaranteed to be the same. In CF-netCDF a cell topology construct can only be provided by a UGRID mesh topology variable. The construct array is supplied either indirectly by any of the UGRID variables that are used to define a domain topology construct, or directly by the UGRID "face_face_connectivity" variable (for face cells). From 5f72640e04391fb486ec3d9e0e177bd4c43732db Mon Sep 17 00:00:00 2001 From: David Hassell Date: Mon, 2 Oct 2023 09:11:49 +0100 Subject: [PATCH 51/53] clarity --- appi.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/appi.adoc b/appi.adoc index 6c8767a8..52de8769 100644 --- a/appi.adoc +++ b/appi.adoc @@ -417,7 +417,8 @@ The spatial dimensionality property is provided by the "location" attribute of a A single UGRID mesh topology defines multiple domain constructs and defines how they relate to each other. For instance, when "face_node_connectivity" and "edge_node_connectivity" variables are both present there are three implied domain constructs - one each for face, edge and point cells - all of which have the same mesh and so are explicitly linked (e.g. it is known which edge cells define each face cell). -The CF data model has no mechanism for explicitly recording such relationships between multiple domain constructs, however whether or not two domains have the same mesh may be reliably deternined by inspection, thereby allowing the creation of netCDF datasets containing UGRID mesh topology variables. +The CF data model has no mechanism for explicitly recording such relationships between multiple domain constructs. +Whether or not two domains have the same mesh may be reliably deternined by inspection, thereby allowing the creation of netCDF datasets containing UGRID mesh topology variables. The restrictions on the type of mesh that may be used with a given cell spatial dimensionality excludes some meshes which can be described by an undirected graph, but is consistent with UGRID encoding within CF-netCDF. UGRID also describes meshes for three-dimensional volume cells that correspond to a volume enclosed by a set of faces, but how the nodes relate to volume boundary vertices is undefined and so volume cells are currently omitted from the CF data model. From 5a8fc6f93b59471d7489ecd93e576ac87176e698 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Thu, 12 Oct 2023 08:58:12 +0100 Subject: [PATCH 52/53] Conventions attribute UGRID --- ch02.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch02.adoc b/ch02.adoc index eab1368d..3d893bf4 100644 --- a/ch02.adoc +++ b/ch02.adoc @@ -167,7 +167,7 @@ If the string contains any commas, it is assumed to be a comma-separated list. When CF is listed with other conventions, this asserts the same full compliance with CF requirements and interpretations as if CF was the sole convention. It is the responsibility of the data-writer to ensure that all common metadata is used with consistent meaning between conventions. - +The UGRID conventions, which are fully incorporated into the CF conventions, do not need to be included in the **`Conventions`** attribute. [[description-of-file-contents, Section 2.6.2, "Description of file contents"]] ==== Description of file contents From 7fc0c042ec2d3234340016e9b7a32a3d51e42591 Mon Sep 17 00:00:00 2001 From: David Hassell Date: Fri, 13 Oct 2023 13:06:00 +0100 Subject: [PATCH 53/53] include figure I.5 in list of figures --- toc-extra.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/toc-extra.adoc b/toc-extra.adoc index 6f7164fd..43b4e659 100644 --- a/toc-extra.adoc +++ b/toc-extra.adoc @@ -26,6 +26,7 @@ I.1. <> I.2. <> I.3. <> I.4. <> +I.5. <> J.1. <> J.2. <> J.3. <>