⇐ ⇒

[CF-metadata] grid cells with a varying number of cell bounds

From: Chris Barker <chris.barker>
Date: Tue, 2 Jan 2018 14:25:40 -0800

On Tue, Jan 2, 2018 at 12:52 PM, Charlie Zender <zender at uci.edu> wrote:

> > By the way, the UGRID standard maps pretty well to how unstructured grid
> > models generally store their grids and read and write them anyway, so it
> > shouldn't be a heavy lift to support it.
>
> Chris, I think you underestimate the work required.
> Many models on unstructured grids (e.g., CAM-SE, MPAS)
> use CF conventions for their native grid output, yet
> do not include much if any mesh connectivity information.
>

most of the mesh connectivity information is optional in UGRID:

http://ugrid-conventions.github.io/ugrid-conventions/#2d-triangular-mesh-topology

all that is required is:



cf_role mesh_topology
topology_dimension 2
node_coordinates
face_node_connectivity

You clearly can't do without node coordinates, and face_node_connectivity
is how you map the nodes to the faces -- i.e. each face is defined by a
particular set of nodes, without that, you don't have a grid.

You may have data only nodes without any grid info, but that would be a bit
too lossy for my taste, and we wouldn't be having the discussion anyway --
that's clear how to represent.

So I'm not sure what the problem is here ?

that only have lat, lon, and gridcell vertices.
>

IIUC, then you have all the required elements -- gridcell vertices Is
face_node_connectivity, I think.

Groups that are already running CMIP6 experiments might
> prefer that new output requirements like UGRID be deferred
> until CMIP7 :)


This isn't my baby, I'm simply suggesting:

If there is information about the grid that can't be represented only with
current CF standards (and CF does not include one clear way to represent an
unstructured grid)

Then you have three choices:

1) don't specify a standard way to do it, which seems like a really bad
idea.

2) make up a new standard for CMIP

3) use UGRID

If CMIP is well on the way with a standard already, then I guess (2) it is,
but even then, if there are still pieces to clarify, then you might as well
borrow from UGRID.

Now I'll editorialize a bit:

I got involved with UGRID because I am primarily a user of model data,
rather than a creator, and the number of unstructured grid models has
greatly increased in the last 10 yrs or so. CF is great for structured
grids -- I can write my code to read CF-compliant results, and then I can
work with any old model out there.

But there was no such standard for unstructured grids, so everyone did
their own thing, and this was a big pain in the neck. Even worse a number
of folks write their model output without preserving the grid info at all,
and while that is OK if I want to, say, plot arrows indicating velocity at
the nodes, it is not so great if I need to properly interpolate, etc.

So if CMIP is "allowing" folks to put out their model results without
properly specifying the grid, then important information is being lost, and
if folks are providing the grid specification, then wouldn't you want it in
an appropriate efficient and standardised format?

-CHB




-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180102/df09de2b/attachment.html>
Received on Tue Jan 02 2018 - 15:25:40 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒