SubmeshHierarchy by pefarrell · Pull Request #5083 · firedrakeproject/firedrake

pefarrell · 2026-05-07T06:19:21Z

This PR was generated almost entirely by Claude Code (and then almost entirely rewritten by @pbrubeck).

Description

Introduces SubmeshHierarchy that simply wraps HierachyBase(Submesh) to enable geometric multigrid on multidomain problems with Submesh

This PR also adds the first demo explaining Submesh and Measure intersection.

pbrubeck · 2026-05-07T07:01:45Z

I think some discussion must happen before opening such involved AI-generated PRs. In particular I am not sure if this is the intended way of composing MeshHierarchy and Submesh.

What happens if one creates the Submesh on the base mesh instead?

     base = UnitSquareMesh(4, 4) 
     sbase = Submesh(base, subdim=1, subdomain_id=3)
     mixed_base = MixedMesh([base, sbase])
     mh = MeshHierarchy(mixed_base, 1) 
     mesh, smesh = mh[-1]

pefarrell · 2026-05-07T19:45:17Z

Updated the PR to address Pablo's review feedback. Summary of changes:

mesh.py: Dropped _create_submesh_raw entirely (as Pablo suggested). The body is back inline in Submesh, with three new attributes added at the end (_submesh_label_name, _submesh_label_value, _submesh_ignore_halo) so that MeshHierarchy can replay the same filter at each refinement level.

mg/mesh.py: Replaced the _build_submesh_hierarchy_for_level / _submesh_coarse_to_fine_cells helpers with Pablo's architectural approach from PR #5084:

MeshSequence dispatch at the top of MeshHierarchy (builds independent hierarchies for each component, wraps fine meshes in MeshSequenceGeometry)
submesh_parent branch: re-applies dmcommon.submesh_create to each level of the pre-existing parent hierarchy rather than refining the submesh DM directly
coarse_to_fine_cells for submesh pairs delegates to the same impl.coarse_to_fine_cells as volume meshes (correct because submesh_create preserves the consecutive child-numbering invariant)

test: Updated to use the explicit MeshHierarchy(submesh, nref) API — build the volume hierarchy first, then build the submesh hierarchy.

All three GMG tests (hierarchy construction, fieldsplit GMG, monolithic GMG) pass.

dham

Aside from the couple of things we discussed in the demo, this is good to go.

We agreed that strictly additive features like this can go to release.

Replace the implicit Submesh(mh[-1], ...) approach with Pablo's explicit MeshHierarchy(submesh, nref) API. Three architectural changes: * mesh.py: Drop _create_submesh_raw; inline the body back into Submesh and store _submesh_label_name / _submesh_label_value / _submesh_ignore_halo so that MeshHierarchy can replay the same filter on each parent level. * mg/mesh.py: Add MeshSequence support at the top of MeshHierarchy (builds independent hierarchies for each component, wraps fine meshes in MeshSequenceGeometry). Add submesh_parent branch: for a Submesh, re-apply dmcommon.submesh_create to each level of the pre-existing parent hierarchy rather than refining the submesh DM directly. Remove the now-superseded _build_submesh_hierarchy_for_level and _submesh_coarse_to_fine_cells helpers. The coarse_to_fine_cells computation for submesh pairs is delegated to the same impl.coarse_to_fine_cells call as for volume meshes, which works because submesh_create preserves the consecutive child-numbering property. * test: Update test_submesh_mg.py to use the new explicit API (build parent hierarchy first, then call MeshHierarchy(submesh, nref)). The dmhooks.py / mg/embedded.py / mg/ufl_utils.py fixes from the previous commit are kept unchanged. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-authored-by: Pablo Brubeck <brubeck@protonmail.com>

pefarrell requested a review from pbrubeck May 7, 2026 06:19