Skip to content

Mutable FunctionSpaces - #5243

Closed
achanbour wants to merge 9 commits into
mainfrom
achanbour/mutable-fs-on-vom
Closed

Mutable FunctionSpaces#5243
achanbour wants to merge 9 commits into
mainfrom
achanbour/mutable-fs-on-vom

Conversation

@achanbour

Copy link
Copy Markdown
Contributor

This PR describes my first attempt at making FunctionSpaces mutable. Note: this currently only works for FS defined on VOMs (the generalisation to arbitrary meshes is TBD).

The main idea is that FS need to detect somehow that the VOM, against which they were built, has changed (topologically). We want this is to be done lazily. This is because there are usually a large number of FS laying around and there is no straightforward way of keeping track through all of them: from the mesh's perspective, FunctionSpaces with the same element, DoF layout etc. share the same _shared_data object cached on the mesh - aFunctionSpaceData object carrying all topology-derived numerical data.

Using this cached attribute allows us to invalidate the FS at the mesh level. At the same time, we want each FS to detect this invalidation and to refresh itself upon on its own first use after the VOM has mutated. Mutating the VOM does the following:

  1. invalidates all the topological properties relating to FS defined on it: topology._shared_data.clear()
  2. bumps the version number stored on the mesh topology object: topology._topology_version += 1

The lazy FS rebuild is implemented here as follows:

  1. first, stash the mesh topology version on the FS object
  2. add a version check at the upstream source i.e., _shared_data which, upon detecting a topology version mismatch, causes all the attributes to be recomputed (refresh_shared_data calls get_shared_data which returns a new FunctionSpaceData object with the updated data)
  3. re-set all the downstream topology-depend properties using the updated _shared_data
  4. sets the FS topology version tracker to the current VOM topology version

To trigger the indirect rebuild, cached properties such as cell_node_list (derived from _shared_data) were turned into version-gated properties (which execute steps 2-4 upon a version mismatch). This required changing these properties from being @cached_property to being plain @property with their own caching mechanism. All other, non-topology-related properties were kept as @cached_property.

Final note: The version gating mechanism described above has only been implemented for FunctionSpace and has not been ported yet into MixedFunctionSpace.

@achanbour
achanbour requested a review from connorjward July 13, 2026 17:20

@connorjward connorjward left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't provide any mechanism for migrating functions when the topology changes. Without that something like

vom = VertexOnlyMesh(...)
V = FunctionSpace(vom, ...)
f = Function(V)

vom.migrate(...)

assemble(f*dx)  # will be absolute gibberish

Comment thread firedrake/functionspaceimpl.py Outdated
Comment thread firedrake/functionspaceimpl.py Outdated
Comment thread firedrake/functionspaceimpl.py Outdated
achanbour

This comment was marked as off-topic.

Comment thread firedrake/functionspaceimpl.py Outdated
Comment thread firedrake/mesh.py Outdated
Comment thread firedrake/mesh.py
Comment thread firedrake/functionspaceimpl.py Outdated
@achanbour
achanbour force-pushed the achanbour/mutable-fs-on-vom branch from 55f80cf to 88add8a Compare July 17, 2026 13:09
@achanbour

Copy link
Copy Markdown
Contributor Author

I think we can close this PR given that it's been moved, along with the other VOM-related mutation, stuff into #5294

@achanbour achanbour closed this Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants