SU2
SU2 copied to clipboard
su2code
NEMO symmetry boundary condition problem
Describe the bug This is not a bug, rather it is a defect in the implementation of the symmetry boundary conditions. The pressure field show imperfections in the vicinity of the symmetry plane whereas the temperature field seems to be fine, as can be seen in the attached figure. Of note, although the attached result and corresponding config and mesh file belong to SU2-NEMO (i.e. non-equilibrium), this problem exists for the SU2 branch, based on private communication with @WallyMaier and @jtneedels. This case is Argon flow over a cylinder at Mach 7.68 with a freestream pressure of 50Pa.
To Reproduce Please find the attached config and mesh file.
[configmesh.zip](https://github.com/su2code/SU
2/files/8619649/configmesh.zip)
This looks painfully similar to the initial fix in https://github.com/su2code/SU2/pull/657 . But Nemo does not implement its own BC_Sym_Plane and uses the standard FVM implementation.
FYI : Another symmetry related issue is https://github.com/su2code/SU2/issues/1125
Update to my comment above ~~But Nemo does not implement its own BC_Sym_Plane and uses the standard FVM implementation~~ ...turns out Nemo uses its own implementation. So Please re-use / adapt the one in CFVMSolver
Thank you @TobiKattmann, the previous symmetry issues were very helpful for us to narrow down the problem. It is obvious that NAVIER_STOKES (SU2 EQUILIBRIUM) solver with the STANDARD_AIR model doesn't have the issue any longer, as opposed to NEMO_NAVIER_STOKES. I ran the same case with the standard air, see the attached. We (@WallyMaier and @jtneedels) will take care of the SU2-NEMO part.
Adding on here: we also observe a similar issue with inviscid simulation in NEMO. I've run the same case with NEMO_EULER_SOLVER and still observe a defect at the stagnation point. I implemented a mirrored state for the evaluation of the convective fluxes, following the procedure of the symmetry BC implemented in CFVMFlowSolverBase.inl, and I still observe the issue. I've zoomed in on the stagnation point here.
I'll add that when I run the same case with standard air (EULER_SOLVER) with MUSCL turned off, I get the same behavior, though it goes away when MUSCL is turned on.
An update here. I did some digging and saw there was a previous PR #1168, where Fabio looked at this issue and implemented a fix for NEMO about 1.5 years ago. It looks like the results were great, but the PR never got merged in. If I pull the most recent commit and run this test case on it, it looks like it solves the issue.
It sounds like we might be able to address this by merging this branch into current Develop and opening a new PR. @TobiKattmann Thoughts on this approach?
It needs cleanup @jtneedels, but it had potential to also solve #1125 so I'm in favor.
@pcarruscag Okay, sounds good. I just wanted to check before I deep-dived into merging. As I understand it, the way Fabio implemented this it is specific to NEMO. To address #1125 it sounds like we would want to generalize to the full code?
Yep, having the implementation in CFVMFlowSolverBase should be enough. And I think there were some geometry modifications that need to be moved to one of the geometry classes, to make sure everything works when we have deforming meshes.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still a relevant issue please comment on it to restart the discussion. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}