The order in which the corner nodes of a volume are specified

[davidhassell]

Hello,

The UGRID documentation (http://ugrid-conventions.github.io/ugrid-conventions/#fully-3d-unstructured-ie-non-layered-mesh-topology) says:

The order in which the corner nodes of a volume are specified is fixed given its shape; this approach is common in 3D modeling, see e.g. this graph in the OpenFOAM documentation and ParaView or VTK documentation.

The linked OpenFOAM documentation seems clear (apart from, perhaps, its different use of the word wedge), but I could not find the equivalent information from the ParaView nor VTK links.

Whilst the UGRID documentation does say that the corner node order is fixed, given its shape, it doesn't tell us what that order is - rather it tells us that other libraries/standards also fix a shape, but allows for the possibility that different libraries fix different shapes.

Would be possible to define the ordering within the UGRID docs?

This would, I think, remove the ambiguity and also remove any potential reliance on an external link for this important information.

I'm coming at this from a CF perspective, for which the order of corner nodes needs to be well defined.

Many thanks,
David

[hrajagers]

Hi David,

We included the fully 3D unstructured option in the initial discussions mostly to test whether the concepts and terminology would hold if we needed to go to fully 3D (and to verify whether they would be consistent with other 3D storage conventions), but I'm not aware of anyone actually using the fully 3D option (I think that the Fluidity-ICOM were missing the finite element function space description). That probably explains why the ambiguity in the 3D numbering still remains.

If that's true, I think that there are two possible ways forward:

1. Explicitly define the numbering for fully 3D meshes and move forward.
2. Drop the fully 3D meshes from the UGRID convention until someone actually needs it.

Does anyone have a preference for the former or the latter?

[davidhassell]

Thanks, Bert, that all makes sense.

I might favour option 2., and not just because that sounds the easiest option!

@JonathanGregory and I recently realized that 3D cells would require a change to the CF data model to allow their bounds to be correctly interpreted, which is why I was thinking about this in the first place. This CF data model change required is quite minor, independent of any other changes that may be on the horizon (such as creating a place for cell connectivity in the CF data model), and absolutely not a problem, but if there is no current use case for it then I'd be just as happy to implement it as and when the use case arose.

That all said, it's also certainly fine by me if you want to go with option 1.

Thanks,
David

[ChrisBarker-NOAA]

Thanks, @hrajagers, @davidhassell.

I would think that unless someone that wants to use UGRID for 3D cells steps up to take this on, we do option 2, and worry about adding that in in a future version if/when it comes up.