Skip to content
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

Open
wants to merge 17 commits into
base: develop
Choose a base branch
from
Open

Fix curved symmetries #2460

wants to merge 17 commits into from

Conversation

bigfooted
Copy link
Contributor

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.

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

…iable

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
@rois1995
Copy link
Contributor

rois1995 commented Mar 6, 2025

Is this related to the problems I was encountering in #2390?

@bigfooted
Copy link
Contributor Author

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?

@rois1995
Copy link
Contributor

rois1995 commented Mar 6, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants