single-cell periodic quad work

[ThighamOxford]

Support single-cell doubly periodic quadrilateral closure

Handle the four-entity DMPlex closure that occurs for a single quadrilateral cell periodic in both directions.

DMPlex returns the unique cell, two edges, and one vertex. Expand these to the nine local entities expected by Firedrake by repeating each edge twice and the vertex four times, analogous to the existing nclosure == 6 handling.

Description

This is a draft implementation adding closure ordering support for a single quadrilateral cell that is periodic in both directions.

DMPlexGetTransitiveClosure returns only the four unique entities in this case: one cell, two edges and one vertex. Firedrake's quadrilateral closure ordering expects the nine local entities of the reference quadrilateral.

This change handles the nclosure == 4 case analogously to the existing nclosure == 6 handling, repeating the two edges and single vertex to construct the expected nine-entry local closure.

With this change, PeriodicRectangleMesh(1, 1, ..., direction="both", quadrilateral=True) successfully constructs and produces the expected cell closure.

Still to do / discussion

The continuous coordinate field is degenerate for a one-cell periodic direction. I have verified locally that constructing DQ1 coordinates and passing them through _postprocess_periodic_mesh gives the correct localized geometry. My test problem is a 2π×2π one-cell torus on which I integrate 1 to get an area of 4π.
Without the DQ coordinate postprocessing, I think the 1 × 1 doubly-periodic PeriodicRectangleMesh has only a single coordinate value (0, 0), since all four corners are identified with the same topological vertex. This results in a geometrically collapsed cell (zero area). I think this also holds for the 1 x ny, and nx x 1 doubly periodic cases where ny, nx >1.

I'm opening this as a draft while working out the preferred way to integrate the localized-coordinate handling into PeriodicRectangleMesh, and would welcome guidance on whether reusing _postprocess_periodic_mesh is the intended approach.

Equally I might be incorrect!

[connorjward]

I don't think you need to do anything around DG coordinates. It should just work.

Could you add a test for this? Probably in https://github.com/firedrakeproject/firedrake/blob/main/tests/firedrake/regression/test_mesh_generation.py using existing tests as inspiration.