Full support of mixed-order elements in DG

Issue/feature addressed

In Nektar++, creating and manipulating the trace space is the key to discontinuous Galerkin discretization. Although Nektar++ already have a lot of ingenious designs to support mixed-order elements in DG, currently it is only valid for isotropic elements (e.g. Hex{nm=2,2,2;np=3,3,3} and Hex{nm=3,3,3;np=4,4,4}. It cannot work with anisotropic elements. For example, the left side is Hex{nm=2,3,4;np=3,4,6} while the right is Hex{nm=3,4,4;np=4,5,5}.

Although anisotropic hexahedra elements are seldom used, checking face orientation is still necessary for Tet, Pyr and Prism because the two bases of the triangular face are always different (Modified_A + GLL v.s. Modified_B + GR).

This merge request tries to resolve this issue.

Proposed solution

The trace space is created by one of the ExpList constructors. It compares the left and right local traces and fetches the higher-order basis keys, which are later used to create the trace expansion. However, the original design does not take into account the face orientations, which causes errors.

The proposed solution is adding the face orientation check during this procedure. For example,

• If the left and right local traces are Quad{nm=2,3;np=3,4;orien=9} and Quad{nm=3,4;np=4,5;orien=9}, respectively, then the trace exp will be Quad{nm=4,3;np=5,4} instead of Quad{nm=3,4;np=4,5} due to orient=eDir1FwdDir2_Dir2FwdDir1;
• If left and right are Quad{nm=2,3;np=3,4;orien=5} and Quad{nm=3,2;np=4,3;orien=5}, then the trace exp will be Quad{nm=3,3;np=4,4}.

bndCondExp should have the same orientation with traces, so checking orientation is also required here. GetFaceBasisKey has the same purpose as GetTraceBasisKey but it is proved to be faulty, so I replace it with GetTraceBasisKey. In order to use this function, a temporary StdExp is created. After this change, GetFaceBasisKey is no longer used and can be removed in the future.

The interpolation and ordering between trace space and local traces is completed in LocTraceToTraceMap. The GetTraceToElementMap and ReOrientTracePhysMap are used to get coeffs and phys reordering maps, respectively. I respect their original design and did not modify them, but I need to swap their inputs (nm0,nm1 or np0,np1) if orient>=9, in order to get the correct results.

Implementation

• ExpList.cpp/trace expList constructor Add face orientation check and swap BasisKey returned by GetTraceBasisKey if necessary. Check pointsType and adjust the points number if one side is GLL and the other side is Gauss-Radau.
• ExpList.cpp/bndCondExp constructor Similar as above. Replace GetFaceBasisKey() and GetEdgeBasisKey() with GetTraceBasisKey() to get the correct results.
• LocTraceToTraceMap/Setup Swap nm0,nm1 or np0,np1 if orient >=9. Also, fix some bugs in the interpolation.
• StdTriExp.cpp/v_GetTraceBasisKey Add more switch cases to handle various bases, so that it can fully replace GetEdgeBasisKey.
• MeshGraph.cpp After this MR, GetFaceBasisKey() and GetEdgeBasisKey() are no longer used, so we remove them.
• HexExp.cpp/v_ComputeTraceNormal Fix a typo.
• TriExp.cpp/v_ComputeTraceNormal Fix the wrong number of trace points.

Tests

The test case Advection3D_DG_hex_varP_faceRotation.xml is based on the existing one, Advection3D_DG_hex_faceRotation.xml, which includes two m8n8 hex elements and all kinds of face orientations. Now I set different nm and np for the two elements (hex{nm=7,8,9;np=9,9,10} and hex{nm=8,7,8;np=9,8,9}). The error norm is now about twice as large as the original one, which I think is reasonable.

Suggested reviewers

@ccantwel @dmoxey @ssherw

Notes

This work is based on !1603 (merged) in order to get correct collections for anisotropic elements. This work mainly handles mixed-order Hex elements. More shape Types will be supported in the future

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).