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.

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