Skip to content

Conversation

@connorjward
Copy link
Contributor

@connorjward connorjward commented Jan 11, 2024

Replace PyOP2 with pyop3.

Thesis link

Summary

Data structures for unstructured meshes are much more complicated than N-dimensional arrays. Firedrake therefore does an awful lot of very involved bookkeeping to make sure that things work.

The key contribution of pyop3 is a new abstraction for describing data layouts, called axis trees. Axis trees are able to describe mesh data layouts completely from a high-level specification. This has the dual set of benefits of: (a) being able to delete a lot of complex Firedrake code, and (b) we can now express a whole suite of algorithms that would otherwise be very difficult to write.

You can think of pyop3 as 'a JIT-compiled numpy for unstructured mesh data'.

pyop3

Core concepts

Expected benefits

API changes visible in Firedrake

Drop support for variable layer extruded meshes

Users should use a cell submesh instead to get the right behaviour.

Explanation

The functionality appeared not to be used by the community (e.g. thetisproject/thetis#405) and porting the functionality would have been a large amount of work.

.sub() expects a tuple instead of integer for tensor spaces.

@connorjward connorjward changed the title pyop3 (WIP) pyop3 Mar 21, 2024
--global and others added 30 commits January 13, 2026 13:19
* Ensemble fixes (slightly API breaking)
* Remove refs to layout_vec in favour of template_vec
Needed for packing mixed things with transforms.
Still getting some failures for diagonal assembly.
I've observed that the cell-node list is different for degree>=3 which
might be causing issues. Therefore I'm trying to apply the orientations
to every pack operation.
Key is that the heuristics were local and so the materialisation steps
would diverge. We now have compute-rank-0-then-bcast strategy that works
and is hopefully not too expensive.
This is tricksy because it means that we apply bizarre permutations for
simplex and quad meshes that we don't strictly need to, but it's
consistent with the current approach.
Sheesh that was difficult! Things still appear to be very slow.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants