Differences on Cfx between JST and ROE at symmetry plane

[EttoreSaetta]

Describe the bug
Hello to everyone,
my research group and I found some differences in the computation of the skin friction coefficient between the JST and ROE schemes near the symmetry plane.
The difference is that when using the JST scheme, there is a gradient of the skin friction coefficient at the symmetry plane.
I expect that on the symmetry plane there would be no gradient. This issue is present only for the skin friction coefficient.
We found this difference for a straight wing, but we reproduced the same issue for the SU2 test case OneraM6.

For the case of our straight wing, maybe it could be more clear, so here is the comparison for our case.

I think that there could be a problem on the symmetry plane boundary condition when using the JST scheme.
This issue is present since SU2 V6.2.0 until the latest release 7.0.8.
Thank you in advance for your help.

To Reproduce
To reproduce the problem you can use the OneraM6 test case in the TestCases folder, just changing the scheme between ROE and JST.

Desktop (please complete the following information):

• OS: Linux (Ubuntu 20.04.1 LTS)
• C++ compiler and version: gcc 9.3.0
• MPI implementation and version: mpich 3.3.2
• SU2 Version: from 6.2.0 to 7.0.8

[TobiKattmann]

Hi, I'll give it a look until end of the week and see if I understand what is happening.
Introduced in #657

[EttoreSaetta]

Hi, I'll give it a look until end of the week and see if I understand what is happening.
Introduced in #657

Thank you so much for the attention.

[pcarruscag]

Hi Ettore, have you tried lowering the 4th order dissipation coefficient? This may be related to how the Laplacians are computed on boundaries.

[pcarruscag]

The logic when computing the Laplacians (used for 4th order dissipation) is that for points on a physical boundary, only other physical boundaries are considered when adding solution differences.
I think this is to avoid adding very large differences for wall points. However when we have a point at a wall-symmetry intersection, the wall point will receive contributions from the symmetry points since that is also a "physical boundary".
That is my hypothesis anyway, anyone care to run some tests? :)

[vdweide]

A good way to test this is to mirror the grid and run the full geometry. I guess the kink in the Cf will disappear for JST. That means that the symmetry boundary condition treatment can be improved, because you want to reproduce the solution for the full geometry exactly when using a symmetry plane.

[EttoreSaetta]

The logic when computing the Laplacians (used for 4th order dissipation) is that for points on a physical boundary, only other physical boundaries are considered when adding solution differences.
I think this is to avoid adding very large differences for wall points. However when we have a point at a wall-symmetry intersection, the wall point will receive contributions from the symmetry points since that is also a "physical boundary".
That is my hypothesis anyway, anyone care to run some tests? :)

Thanks you for the hint, I am running some tests using different values of the 4th order dissipation coefficient for the OneraM6 test case.
Lowering this value, as expected, increase the oscillations of the JST scheme. Anyway the problem is still there.
What looks strange to me is that this difference is present only for the skin friction coefficient and not for the other variables.
Is it possible that the problem is due to the computation of the Cf?

[MiGaff]

I remember having the same problem when computing impinging jets flows on a hot surface in symmetric configurations. The maximum heat flux should be at the stagnation point of the jet (which is in the symmetry plane) but the simulation predicted the maximum at some distance from the symmetry. Mirroring the mesh and computing the full geometry led to the correct solution.
I was using JST but didn't test with upwind schemes for comparison. I may do so if I have some time.

[pcarruscag]

Still an important correctness issue in the code.