What remains for complete UGRID support

[pp-mo]

Since we have aimed at Iris supporting 'any' UGRID data (not specifically LFRic/XIOS data), it would be great if we could claim that.
However, even though UGRID is fairly small+simple, we are still currently short in some areas.

So, since I've been thinking about this + made a list, I thought I should share it.
Here's my hitlist ...

1. support "location index sets"
2. Mesh object to handle coords with no identifiable axis
3. MeshCoord rework to support bounds without points
4. support 3d meshes (i.e. volume elements, or topology_dimension==3)
5. support node-only meshes (i.e. no edges or faces, topology_dimension==0)
6. add UGRID to file conventions

If we hit all those, then I think we can claim to read any UGRID (excluding errors to be fixed!).

---

details (to expand further as we go?) ...

(1.) Location Index Sets

In Iris at present: don't interpret these objects,

• they will appear as extraneous cubes on load.
• data-variables using them will not load with a mesh

These are "a thing" in UGRID
They allow data to be mapped to a subset of mesh points
In Iris, this would enable us to sub-index unstructured cubes without losing the Mesh, as we do at present.
This would also assist handling of sub-mesh data, e.g. as in the planned 'recombine' operation.

Unfortunately it will complicate things somewhat, as -- unlike MeshCoords -- a LocationIndexSet object will have to be a first-class Iris datamodel object, since it contains an index array which relates to a actual file variable (hence, at least, a var_name and attributes).
Effectively, a LocationIndexSet will be to a Cube more-or-less what a Mesh is, but must also link to a separate Mesh object (with it's own file-variable references).

(2.) Mesh to handle Coords with no "axis"

In Iris at present: can't load UGRID files where coordinates have no suitable CF standard_name (get an error)
Our existing code organises coords of a Mesh into x- and y-axes.
This is a user convenience, but doesn't support the full generality of UGRID.
Iris generally uses guess_coord_axis to assign axes,
in particular to Mesh coords, which currently require it

• this works for things with a recognised standard_name (and appropriate units).
• it does not apply to coords without suitable standard-names, as is common in general UGRID files

In UGRID:

• there is no requirement whatsoever for identifying what coords "are"
• but of course we generally expect to use CF
• N.B. there is no mathematical requirement even to use 2 coords to describe 2d geolocations :
  • cartesian coords might be XYZ
  • a "Google S2 coordinate" or similar might have just a single coord value to identify any surface location
• .. so I think each location should just reference some N coords : A "meaning" for the coords is not part of UGRID, and should not be required by the Mesh object.

(3.) MeshCoords with bounds but no points

In Iris at present: cannot load face- or edge-based data with no corresponding face- or edge-based coordinates (get an error)
For generality we need this, as all face- or edge-coords are strictly optional in UGRID
The refactor could be tricky, as this ability will be unique, so far, amongst Coord types

(4.) 3d meshes / volume elements

In Iris at present: no support (get an error)
UGRID owners are apparently doubting the current proposals for this, and may withdraw temporarily to aid CF integration
However, it is probably in our interests to firm this up, so we can promote future interoperability with finite-element data

(5.) node-only meshes

In Iris at present: no support (get an error) like
Explicitly forbidden, here and here

In UGRID:
There is no explicit description or example in the UGRID pages, but it may be an intended use, and seems at least a simple + natural extension.
We do also have a (really old) file in the iris-test-data that actually uses this form.
The mesh variable there is simply this :

	int Mesh0 ;
		Mesh0:cf_role = "mesh_topology" ;
		Mesh0:long_name = "Topology data of 2D unstructured mesh" ;
		Mesh0:topology_dimension = 2 ;
		Mesh0:node_coordinates = "Mesh0_node_x Mesh0_node_y" ;

N.B. so the topology_dimension here (at least) is clearly wrong !
(by my logic, it should be 0)

(6.) add UGRID to file conventions

Not entirely straighforward as, at present there is some remaining discussion about what the valid form would be :
Not sure if this may have changed with recent netCDF (4.8/4.9 ?), but re-reading, it does now seem clear how to do this.
See #5030

[pp-mo]

Just reviewing this with a thought to Iris 3.2

From the issues listed above , I though I would very quickly rate them for relative "importance" + "difficulty" :

#original	issue	importance	effort
4.	support 3d meshes (i.e. volume elements, or topology_dimension==3)	1	8
5.	support node-only meshes (i.e. no edges or faces, topology_dimension==0)	2	1
1.	support "location index sets"	2	5
2.	Mesh object to handle coords with no identifiable axis	5	5
3.	MeshCoord rework to support bounds without points	8	5
6.	add UGRID to file conventions	1	3

This is completely a personal view !!
Discouragingly, I have to say, the more important ones do also seem to be the harder ones, to me.

[pp-mo]

3. MeshCoord rework to support bounds without points

Actually I think an acceptable solution (interim?) would be to create the MeshCoord with a lazy points array, that simply raises an exception "has no points" if you ever try to compute it.