Eave Mesh Generation - PoC to Main

[mo-rickywong]

Are there any linked Issues or Pull Requests?

No response

Brief description

Proof of Concept (PoC) branch for generation of eave-meshes which support existing science/ancil tools to work with cubed-sphere mesh topologies to be reworked for committing to main.

While science/ancils have found the output from the PoC branch acceptable, the implementation needs to discussed so its acceptable within a OO framework.

Further details of the issue.

C24 Cubedsphere with Panel-5 (top-panel) Eave-Mesh (eave_depth of 3-cells) overlayed

An eave-mesh is named more as a result of it's usage i.e. it's association with a Cubed-Sphere mesh and how it is mapped. though it's topology is closer to a specific configuration of the planar_mesh_type with some extra info/methods relating to the eaves and associated cubedsphere panel. Each eave-mesh is:

• A grid of equal numbers of cells on each edge of the domain. ( of side Cubed-sphere number of panel edge cells + 2xEave_depth, e.g. 30 in the above diagram.
• Geometry=spherical
• Topology=non-periodic
• Coord-system=lon-lat
• Single 1:1 InterGridMap to the associated CudedSphere panel, where the Eave region is set to the void id to indicate there are are no mapped cells there.
• Node coordinate distribution/Mesh element id numberings differ from the planar mesh generator. They are treated in the same manner as the for CubedSphere panel-0
• Eave-mesh connectivity is oriented depending on the associated Cubed-sphere Panel number.

I'd suggest that:

• There is a eave mesh generation strategy object.
• The eave mesh generation object produces eave-meshes which are an extension of the planar_mesh_type, however in infrastructure the is 'planar_mesh_type' all meshes are classed as global mesh type which should probably be made into a class hierarchy.

[mo-rickywong]

Tagging @MatthewHambley @hdyson for discussion / requirements