Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mixed mesh orientation #16872

Merged
merged 9 commits into from
Apr 12, 2024
Merged

Conversation

drwells
Copy link
Member

@drwells drwells commented Apr 8, 2024

In 2d, mixed meshes require quadrilaterals with non-standard face orientations. This patch makes that possible for isotropic refinement by generalizing the triangle orientation code to cover both 2d element types.

I'm working on a follow-up patch which gets rid of some of these assumptions in 2d for FE_Q_Base etc.

Part of #14667.

Quadrilateral cells in mixed meshes may have lines with reversed orientations.
We can make that case work correctly by simply generalizing the code we already
have for triangles.
This fixes quadrilateral orientations on mixed meshes. A minor inconsistency in
this scheme is that the inner triangle faces must have different orientations on
different children.
@kronbichler kronbichler merged commit 11f0589 into dealii:master Apr 12, 2024
16 checks passed
@bangerth
Copy link
Member

Oh, that's a bummer that we can no longer expect to only use standard orientation in 2d :-( I guess that had to happen at some point...

@drwells
Copy link
Member Author

drwells commented Apr 16, 2024

It is a bummer that, e.g., FE_Q et al have to account for this even when they won't be used that way 99% of the time. I don't think that there is a way to have a FiniteElement know whether or not it is in a mixed mesh.

@bangerth
Copy link
Member

The Triangulation class has a function that can be used to query whether a mesh is purely hypercube. But I wouldn't be sure this is faster than what you're doing.

@drwells
Copy link
Member Author

drwells commented Apr 17, 2024

Oh, I see - I was thinking of the other mixed-mesh PR.

That would indeed be faster but I think using the same code path for triangles and quadrilaterals in all circumstances is much easier to understand. We can always go back and special-case quadrilaterals if we need to.

@kronbichler
Copy link
Member

Regarding "much faster", I think we would need to benchmark it. If I remember correctly, I don't think any of those new functions is in the critical path; we do have the access to DoF indices but even there I am not sure how much it really changes, because we have separate paths for the standard case if I remember correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants