Different results between 3D and 2D problems when using JST

[EttoreSaetta]

Issue Description
Dear all,
my research group and me found a problem when using the JST scheme.
The problem consists in a difference in the skin friction coefficient along the airfoil between 2D and 3D meshes (the 3D one is obtained by extruding the 2D mesh using only 1 cell in the span wise direction).
This difference arises when the JST scheme is used, and it leads to a ~25% of difference in the drag coefficient.

In order to better explain what is happening, here is a summary table of the results for the CRM airfoil:

It is possible to notice that this difference does not emerge if the ROE scheme is used.

For the 3D case, the boundary conditions at the side faces of the domain are MARKER_SYM, so that we think that this issue could be connected to the #1125 .

To Reproduce
In order to reproduce the issue, a zip file is attached. It contains the configuration files for the 3D and 2D cases using JST and ROE, and the two grids of the CRM airfoil. It is possible to reproduce this issue also using a different airfoil.

ROEvsJST.zip

Desktop:

• OS: Linux (Ubuntu)
• C++ compiler and version: -
• MPI implementation and version: -
• SU2 Version: v7.1.1 and previous.

Thanks for your help.
Ettore Saetta

Theoretical and Applied Aerodynamics Research Group (TAARG)
University of Naples Federico II

[pcarruscag]

The symmetry implementation uses a numerics class to evaluate fluxes.
For upwind schemes this class is the same as the one used for internal points (but first order).
For central schemes this class is Roe, and so there is a mismatch, which maybe causes these issues.
Have you tried running the 3D slice with periodic conditions rather than symmetry?

IDK why JST was not used for boundaries, I do remember @economon mentioning it had been like that for a very long time.
Using JST for boundaries would require more than just replacing the class, because it requires terms (sensors and laplacians) that are not used by upwind schemes.
Recently there were also talks, between @TobiKattmann and @fmpmorgado of an implementation of symmetry that is independent of numerical schemes (in PR #1168).

[EttoreSaetta]

@pcarruscag thank you for your answer.
We have tried running the 3D case using periodic boundary conditions.
The results are here reported:

Using the ROE scheme there is no problem.
Using the JST scheme the result is better now, but there is still a difference of ~2 counts for the drag coefficient.

The configuration files and the grids are attached here:
Addenda_ROEvsJST.zip

[pcarruscag]

Hi @EttoreSaetta sorry for the late reply. There are some scaling terms in the JST scheme in SU2 that depend on the number of neighbors of each point (which will be different for 2-D and 3-D).
However, they don't explain the complete difference, I tried making them constant but 2-D and 3-D still gave different results, in fact the difference was much larger than in your problem.
I looked in the usual references but could not find an explanation for those terms, but in any case it seems that the main problem is the symmetry boundary condition.

[clarkpede]

Just a comment here, that may or may not help:

The sensor in SU2 is based on an unstructured, 3D generalization of Jameson, Schmidt, and Turkel's original sensor. If s is the sensor and p is the pressure at some cell i, then the sensor is calculated as

If you imagine a problem with constant spanwise properties, you can ask the question, will 2D and 3D simulations give the same value for the shock sensor? The answer is no. The numerator of the sensor will not change, since the pressure is constant across the spanwise direction. But the denominator will change. As you add more neighbors, the value of the denominator will increase, the value of the sensor will decrease, and the dissipation will decrease.

As @pcarruscag mentioned, the stretching terms also have different values in 2D and 3D problems, so that further muddies the waters.

[pcarruscag]

Alright, as Clark mentioned there are aspects of JST that will inherently produce different results in 2D/3D. I'll close this for now, we can reopen if someone starts working on improving JST.