make_face_restriction/DG face mass matrix: Handling elements with different-shaped faces (e.g. pyramids)
- Dominant language
- Python
- Stars
- 34
- Forks
- 25
- Avg merge
- 3h 37m
- Merged PRs (30d)
- 2
Description
Way out there, I know, but @thomasgibson, @lukeolson and I were thinking about it today. Currently, the DG face mass matrix code in grudge assumes that for each volume element, one element per face is generated, winding up with `nfaces * nelements` elements, and that the elements for each face are numbered contiguously. This is not feasible for a pyramid, or any other element type that has more than one shape of face. (Because element groups are numbered contiguously, and the different-shaped face element must be in a different group.) With time, we should probably remove this assumption, and instead move to "face-major" numbering (from "volume-element-major" numbering currently). Unfortunately, this has an efficiency impact in DG, as the face mass matrix must then find its face data from (for e.g. tetrahedra) four different places in memory rather than one contiguous one.
Relevant source: https://github.com/inducer/meshmode/blob/960d740121b0d47989a84301444715cdf642d6ac/meshmode/discretization/connection/face.py#L151
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.