Skip to content

Fix for setting the right optimisation flag for nodes that are on more than 1 curve or surface

Mashy Green requested to merge meshing/nektar:fix/varopti-optiKind into master

Issue/feature addressed

When assigning optiKind (a flag to determine the range of movement a varopti node can have), the code was testing if the node is exactly on a single curve or surface with == 1. Nodes which are also vertices, or node that connect two surfaces, are not caught by this check and are assigned the wrong optiKind flag, which sometimes can cause issues with a node moving away from the CAD instead of sliding on it. This should be caught in the PreProcessing when creating the colourmaps in =GetColouredNodes= but for cases with a mesh on both sides of the curve / surface it doesn't catch vertex nodes that are connected to two curves, so this is an extra catch which should have been there from the start.

Proposed solution

Ensure that the correct flag is assigned to the nodes.

Implementation

Changed the condition from if == to just the if (i.e. anything but zero), which will account for cases where it is on more than a single curve / surface.

Tests

Passes current VarOpti tests as the measures this affects are not something we can account for yet. After we merge the improvements to NekMesh::ProcessJac we might be able to add some measures to test the changes caused by this MR as well.

Suggested reviewers

Dave, Kaloyan, Jingtian

Notes

These changes are also added to MR !1349 (merged).

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 Mashy Green

Merge request reports