[WIP] Fix cornernode normal

[bigfooted]

Proposed Changes

Give a brief overview of your contribution here in a few sentences.
Quick fix to issue #2383
The normal node is the interior node that is most normal to the edge. If the node is on the wall, it is only considered as normal node if no previous normal nodes were detected (just for the case that there are no normal nodes). A normal node that is on the wall can be overwritten by any interior node.

PR Checklist

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.

[pcarruscag]

I don't think this is the full fix.
First issue, at vertices shared by two markers we compute two normals for the same point, potentially resulting in different "normal neighbors". Then the result we get depends on whether markers are merged or not, their order, etc.
Then the distance we should use is the wall distance and not just the straight line between points.

So if you want to do something that doesn't break all cases you have the solution I mentioned in the issue

smallest non-zero wall distance of a neighbor of the wall point.

[bigfooted]

OK, so the 'normal angle' does not matter anymore in that case, we only have edge length (to an interior node) as requirement?

[stevosg99]

I am very interested in a solution to this issue, as this particular bug has caused convergence issues for a long time (especially with the SST Models). Here is a comparison of 8.1.0 (with the corner of issues circled in red) and the fix_cornernode_normal version just created.

It seems to be causing all of the wall distances to be miscalculated now.

[pcarruscag]

We only have wall distance as a requirement, not distance between nodes.

[bigfooted]

OK, I changed it to wall distance.
For the flow over the backward facing step, with a structured mesh as shown, the corner node iPoint does not have any connecting nodes jPoint that are in the interior. In this case, You can loop over the nodes jPoint and check those points for interior points.

But still, the corner node has zero shear stress, so y+ = 0 in that case. But I do not think that this is problematic.

[pcarruscag]

Good point, in such cases we can probably use cbrt of the volume at that point to avoid a 0.
My suggestion is to change just the SST wall boundary condition and avoid touching the normal neighbor all together because it impacts too many things in the code.

[bigfooted]

I can introduce FindClosest_Neighbor, and use that for the walls in TurbSSTSolver. We can then phase out FindNearest_Neighbor over time.

[pcarruscag]

Just do what you need to do in the SST wall boundary condition for now

[rois1995]

Y plus value of zero just means that the skin friction is zero there, right? which is expected since it is a stagnation point. Thus I don't understand where a division by zero should be occurring. Moreover, why are we computing the distance again to search for the closest one? Shouldn't we use the wall distance already computed?