You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
inducer
changed the title
make_face_restriction/DG face mass matrix: Handling elements with different-shaped faces
make_face_restriction/DG face mass matrix: Handling elements with different-shaped faces (e.g. pyramids)
Apr 7, 2021
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:
meshmode/meshmode/discretization/connection/face.py
Line 151 in 960d740
The text was updated successfully, but these errors were encountered: