Skip to content

Fix explist::v_GetNormals and GetElmtNormalLength

BOYANG XIA requested to merge xby2233/nektar:fix/explist_get_normals into master

Issue/feature addressed

This is an extension of the merge request !1606 (merged). We fix and clean up the Explist::v_GetNormals() and Explist::GetElmtNormalLength() functions so that they can work with variable-polynomial-order elements.

Proposed solution

When computing the normal vectors on the trace space, we need to first find its adjacent element and then call local v_ComputeTraceNormal. It doesn't matter which side (left or right) to use because any curved face shall be precisely described by the element of either side. For convenience, we can directly use the left side because it always exists.

However, for some unknown reason, GetElmtNormalLength() is designed to return the length of both sides. Currently, I still follow the original design, but in the future, it should be simplified to return only one arg, the same as GetNormals.

Please note that GetElmtNormalLength() is only used by DiffusionIP to compute the penalty scale factor. If you are familiar with this part of the code, could you give an explanation? thank you!

Tests

New Advection3D test cases are added to ADRSolver to test pyramid and prism elements of variable polynomial orders. e.g. `Prism{nm=4,5,5;np=5,6,5}. Existing Tri and Quad varP cases are modified to include anisotropic elements.

Suggested reviewers

@dmoxey, @CFD-Xing

Notes

Please add any other information that could be useful for reviewers.

Checklist

  • Functions and classes, or changes to them, are documented.
  • [ ] User guide/documentation is updated.
  • Changelog is updated.
  • Suitable tests added for new functionality.
  • Contributed code is correctly formatted. (See the contributing guidelines).
  • [ ] License added to any new files.
  • No extraneous files have been added (e.g. compiler output or test data files).
Edited by Spencer Sherwin

Merge request reports