Skip to content

PerAlign extension for all types of meshes

Issue/feature addressed

This is an extension to the PerAlign module that allows running meshes with Nektar++ that need periodicity in the boundary conditions. The legacy module has some very strict limitations that practically do not fully support runs with meshes other than Hex. If Tets or Prisms are in the mesh the Incompressible solver will correctly throw away an error on the initialization of solver run, whereas for full hex mesh, it will not stop the user to run, but the results will be noisy on the periodicities.

The legacy state is as follows:

  • Fully Hex meshes
    • Working fine for fully hex meshes.
    • Can be called as two separate calls to the ProcessModule also directly on the HO mesh.
    • The reason for that it that it does need the "orient" flag, which calls Module::ReorderPrisms.
    • Guglielmo has already ran successfully LES/DNS cases with the module and GMSH.
  • Fully Tetrahedral meshes
    • Working fine with a single periodic pair only on the linear mesh. The module throws away all HO information of the Tets.
    • NOT working if you would like to impose multiple periodic pairs in a single module call.
    • NOT possible to give multiple inputs.
    • NOT useful to run multiple times the command : you need to pass "orient" flag, hence ReorderPrisms will delete all vertex IDs.
  • Hybrid Tet-Prism meshes
    • Same as fully Tet +
    • NOT working if ran on a wall that has prism quad faces attached to it and PerAlign ran on the linear mesh. After the prisms are split ( both with the legacy and the new ProcessBL) the expansion orientations are not consistent.
    • NOT keeping the full HO-information. Keeps only the EdgeNodes ( Face Curvature nodes are thrown away in Module::ReorderPrism).

Proposed solution

Current functionalities (New Functionalities)

  • Added functionality to be able to add multiple surface pairs as an option to the module ProcessPerAlign.

  • Added functionality to run with multiple surface pairs ( max 3 at the moment - we can make it a variable) in Module::ReorderPrisms()

  • Fully Tetrahedral meshes

    • Working fine with a single or multiple periodic pairs only on the linear mesh.
    • Working if you would like to impose multiple periodic pairs in a single module call.
    • Made it Possible to give multiple inputs.
    • NOT useful to run multiple times the command : you need to pass "orient" flag, hence ReorderPrisms will delete all vertex IDs.
  • Hybrid Tet-Prism meshes

    • Same as fully Tet +
    • Working if ran on a wall that has prism quad faces attached to it and PerAlign ran only on the FINAL HO Mesh.
    • NOT keeping the full HO-information. Keeps only the EdgeNodes ( Face Curvature nodes are thrown away in Module::ReorderPrism) .

Implementation

  • ProcessPerAlign
    • allow m_config to input a vectors of surface pairs in
      • EXsurf1 = 2,3 : surf2=5,6 - It will create two periodic pairs than could have completely different periodicity configurations: EX: First pair between surfaces 2 and 5. Second pair between surfaces 3 and 6.
      • In order to separate calls for the orient (rotational periodicity) or dir (translational) I have introduced a token separator "!". That is not ideal but the only one I could find working both in Bash (no separate variable created) and C++ since we need to allow the use of both "x,y" as directions and unit vector one "1.0,0.0,1.0" in a single m_config call.
        • EX: -m peralign:surf1=3,8:surf2=5,9:dir=y!0.0,0.0,1.0 - This way the first pair(composites 3,5) will take direction "y" and the second pair (8,9) will take "z", but defined as .
      • I tried to keep the core part of the module as it is. Hence the algorithm on pairing centroids of the boundary faces is not really changed.
    • Splits the pair commands
    • Creates a for loop around the periodic Surface Pairs (pIt) to push back in a single perFace, which is then passed as an argument to orient
    • I introduced a final entry to every perFace vector<int> list denoting the pairID, which allows me to filter the pairID afterwards in Module::ReorderPrisms().
    • In the end of the every surface pair Boundary composite is rearanged as required in Nektar++ ( no vID are changed here)
  • Module::ReorderPrism(perFaces)
    • As beforee all vertex IDs are -1 .
    • As discussed in the meeting - first we give IDs to the periodic vertices( from perFaces) . However:
      • Added an extra loop on top of the elements and running it sequentially based on the pairID. This is where the vertices Since this is a massive unoredered map, the pairID are mixed. Moreover, the corner vertices where the two pairs are done simultanously will become inconsistent if both pairID are giving vertex IDs. This way the expansion are consistent in my test-cases.
    • Added a check in the end if there are vId=-1 . This will be useful if there are also to spot pyramids.

Tests

I have a 3D NACA0012 mesh that I can run with the Incompressible solver for 10 timesteps in 4 (Hex/ Tet/ 2xTet-Prism) different configurations to ensure it is possible. I am not sure how to add these multistage test like:

  1. Create the mesh
  2. Run the solver
  3. Analyze if results continuous

Suggested reviewers

@mgreen @dmoxey

Notes

In order to test that PerAlign works properly, a solver running on a produced periodic meshe is required. To accommodate this additional testing requirement, some changes to Tester were introduced that allow to run sequential tests from a .tst file. These changes are not directly related to issue this MR addresses and in hindsight could be seperated to another MR. If there is no objection it will stay here, however if it makes the review simpler to take them out and create a separate MR for Tester we could do that.

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 Kaloyan Kirilov

Merge request reports