-
Notifications
You must be signed in to change notification settings - Fork 853
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix curved symmetries #2460
base: develop
Are you sure you want to change the base?
Fix curved symmetries #2460
Conversation
…iable Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Is this related to the problems I was encountering in #2390? |
No, this is a fix for nodes that are shared by 2 curved Euler walls. For your issue, I am not sure what the root cause is. Did you work more on this? |
Unfortunately not, I am trying to close some other PR that I have open from long ago. I guess it is still a problem with normals in the point where the slope changes direction. I will try to have a look into it whenever I can. |
Proposed Changes
Give a brief overview of your contribution here in a few sentences.
For nodes that are shared by 2 or more curved symmetries (usually Euler walls) we do not need to apply Gram Schmidt orthogonalization to correct the face normals. Instead, we need to add the normals to retrieve the same normals as if these faces were merged. For straight symmetries (could be euler walls as well but usually symmetry planes) we always perform GSO when nodes are shared with another symmetry (straight or not).
Related Work
Resolve any issues (bug fix or feature request), note any related PRs, or mention interactions with the work of others, if any.
Reported on slack:
"Hi all. I am running a 3D euler simulation on a vehicle. I build the mesh in gmsh. the vehicle surface is composed by several gmsh surfaces. initially I had 1 boundary condition for the whole vehicle surface, with marker name "wall", in which I applied a marker Euler.for mesh adaptation purposes, I need one of the gmsh surfaces to have a different marker name, called "no_adapt", in which I also apply a marker Euler.So I have MARKER_EULER = (wall) vs. MARKER_EULER = (wall, no_adapt)with 1 marker, the surface solution is smooth in the region of interest. with 2 markers, I would expect the same outcome, since I use the same BC, simple divide it with 2 different names. However, the solution at the interface between the two markers goes really weird.I already checked the mesh generation several times and I cannot find any issue on the mesh generation end.So I'm left with wondering if the problem could be on the SU2 side ... Anyone has any feedback on this?"
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.
pre-commit run --all
to format old commits.