Set the symmetry BC mandatorily, only for velocity.

[ShiheJia]

After updating solution and before communications, the normal component is subtracted from the velocity of the sym wall.

Related Work

#1168, #657, #1625, #1125

The symmetry BC in SU2 is waiting for further implementation, for scalar vars and vectors.
But first of all, we should ensure that the wall normal velocity is zero for the sym BC.
When we run an unsteady simulation with sym BC such as the following A-airfoil cases, the spanwise velocity on the spanwise sym BC has a distribution that we donot want to see. (Free stream velocity is 0.15 and the spanwise velocity can exceed 0.01 (the ±0.001 in the figure is to show more clearly) where it should be zero.)
And this PR is to ensure the zero normal velocity.

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

• 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]

Can you show the residual convergence in each time step before and after this change please.

[ShiheJia]

Ok, here is an example. A steady simulation is used and the relevant files are attached below.

The geometry is A-airfoil case with AoA = 13.3 deg, and the spanwise boundaries are set to MARKER_SYM.

Two cases shown below use the same configuration and mesh file, the only difference comes from the submitted code and the original code.

For the distribution on the sym bc, the spanwise speed keeps zero.

For the history of drag and lift (CSF here for the spanwise direction is z-direction), submitted code shows little differences after convergence.

For the history of the residual, increasing instabilities is not observed.

Relevant files:
cfd.txt
history-original.txt
history-submitted.txt

[pcarruscag]

It looks like your example is only converging a couple orders of magnitude, have you tried running it for more iterations or tweaking the settings?
Have you tested this fix on the cases of the related issues? Does this change improve those results?
Have you tested this strategy for curved Euler (slip) walls, which share the implementation with the symmetry plane boundary.

[bigfooted]

This is inconsistent with the current implementation. The symmetry boundary condition that is implemented is using the reflection tensor $$\bf{R} = \bf{I} - 2n_f \bigotimes n_f$$ and can be found in CFVMFlowSolverBase.inl in CFVMFlowSolverBase<V, R>::BC_Sym_Plane

https://github.com/su2code/SU2/blob/master/SU2_CFD/include/solvers/CFVMFlowSolverBase.inl

You can also see there the implementation of the symmetry boundary condition for the velocity. You are now basically partially overwriting the weakly imposed boundary condition with a strongly imposed boundary condition.

If you want to see a failing testcase you can try your approach with the 90 degree bend tutorial testcase and you will see that the residuals will stall after 100 iterations. With the current implementation in develop you can see that the symmetry boundary is only weakly imposed and does not fulfill the symmetry condition exactly, but the same is true for the inlet boundary condition.

[ShiheJia]

Sorry for the late reply, here are some personal opinions.

(1) I have also test the turb flatplate and Onera M6 case (Fig1.Original; Fig2.Submit) in the tutorials. The convengence and results also shows just slightly difference.

(2) This PR is not suitable for the euler wall, for the wall is not always a straight plane and singular points do not statisfy the condition for the normal direction is hard to define.

(3) Well, I have noticed the BC_Sym_Plane before, but it is very puzzling to me that only the closed point to the vertex on the sym wall is considered to add additional negative normal flux contribution. Maybe the mesh is unstructured and more than one point out of wall is linked to the vortex. Maybe the closed point is not normal to the wall while it always occurs on the 3D sym plane such as the ONERA M6 wing case.

(4) This PR is to add a limitation of the velocity on the sym wall, just like what we do to the turb walls in the CTurbSSTSolver::CTurbSSTSolver(CGeometry *geometry, CConfig *config, unsigned short iMesh). The fix is only available for the SYMMETRY wall and in the implicit iteration, just to avoid uncertainty and potential instability.
`
CTurbSSTSolver::CTurbSSTSolver(CGeometry *geometry, CConfig *config, unsigned short iMesh)
: CTurbSolver(geometry, config, true) {
......

/--- Initialize lower and upper limits---/
lowerlimit[0] = 1.0e-10;
upperlimit[0] = 1.0e10;

lowerlimit[1] = 1.0e-4;
upperlimit[1] = 1.0e15;
`

[ShiheJia]

Here is the files of the ONERA M6 case.
turb_ONERAM6.txt
Original.txt
Submit.txt

[bigfooted]

Hi,
Any progress on this PR? As I said, this implementation is not correct. A car analogy would be that you hear a strange sound coming from your car engine and to fix the problem, you turn up the volume of the radio.
A start would be to read the relevant chapters on boundary conditions in e.g. Blazeks book and then go back to bc_sym_plane and try to understand what is going on there. The reflection condition is reflecting everything, including nonzero normal components of velocity. So the next questions should be where these normal components come from and where to fix them.

[ShiheJia]

Hello,
You are right, this pr cannot solve the problem but just make the solution look reasonable.
For some complicated case, it is hard to converge, not like in the simple cases.
I have read the relevant code and book, and I think maybe a good way is to rewrite the bc code and move the nonzero normal components limitation to where the flux are calculated. Or we can store the flux of the points on the sym bc, and in CFVMFlowSolverBase<V, R>::BC_Sym_Plane we just use the stored flux without recalculation.