Explicitly use the inverse orientation instead of hard-coding. #16916
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.
Partially reverts #15678.
While #15678 fixed the permutation bug, it didn't address the true cause of the problem: since face orientations are computed in the "apply this permutation to face 1 to get face 2" direction, QProjector should use inverse orientations. Since 2d orientations are their own inverses this only shows up in 3d.
Whenever two faces abutt, the first face is always in the default orientation and the second face's orientation is computed relative to that (as decribed here). Hence, when we project quadrature points onto the first face they do not need to reoriented. However, we need to apply the reverse permutation on the second face so that they end up in the same positions as the first face. More formally: most, but not all, orientations are their own inverses. In particular, triangle orientations 3 and 5 are each-other's inverses.
This matches the notion of inverse orientation used in #16828 for hypercubes. In the future, we should combine the hypercube and non-hypercube implementations to avoid these kinds of inconsistencies.
Part of #14667.