Fix check for same face type #14341
Merged
Fix check for same face type #14341
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
One could adopt step-76. But for gradients we would need compressible NS instead of Euler. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I observed that the ECL loop went way too often into the slow branch, and found that we assess the ability to vectorize on whether the cell ids are the same (see #13063), rather than the local face number that actually decides whether the interpolation directions are different or not. @peterrum I think we are in desperate need for a benchmark for the matrix-free DG infrastructure including the ECL setup. I have a Navier-Stokes one that I plan to post in the next days, I have one that would work well already around.
I ran all tests containing the expression
matrix_freeand they are passing.