Fix cornernode normal by bigfooted · Pull Request #2392 · su2code/SU2

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

@bigfooted

@bigfooted

pcarruscag

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

image

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

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

image
image

@bigfooted

@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

@bigfooted

github-advanced-security[bot]

@bigfooted

@bigfooted

@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?

@bigfooted

@pcarruscag do you think this is the way to go? If so, I can clean it up and fix the regressions, that's still a whole bunch.

@pcarruscag

I don't think so.

  • We need the distance projected in the normal direction, not the Euclidean distance.
  • The second search you are using for vertices without an interior neighbor is not valid for MPI, if the vertex is close to an MPI boundary, the second-degree neighbors do not exist.
  • I would rather not add anything to CVertex for now, I'll think about a better way of determining the normal neighbor.

So, in the SST solver, and nowhere else:

  • Loop over the neighbors of the point and find the smallest non-zero wall distance.
  • If that is zero, use 2 * Volume / (sum of vertex areas) as an estimate of the normal distance.

nijso beishuizen and others added 3 commits

February 24, 2025 06:08

pcarruscag

@pcarruscag

@pcarruscag

pcarruscag

@pcarruscag

@bigfooted

Update CTurbSSTSolver.cpp to fix bug on calculating MuT

@pcarruscag

@pcarruscag

@pcarruscag

I'll help update the tests.

@bigfooted

pcarruscag

@pcarruscag

pcarruscag

@pcarruscag