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

Automatically fix orientation of volume meshes from gmsh? #315

Open
inducer opened this issue Mar 27, 2022 · 3 comments
Open

Automatically fix orientation of volume meshes from gmsh? #315

inducer opened this issue Mar 27, 2022 · 3 comments

Comments

@inducer
Copy link
Owner

inducer commented Mar 27, 2022

Given the grief in illinois-ceesd/drivers_y2-isolator#13, I wonder whether it might not be better to automatically fix the orientation of volume meshes coming in from gmsh.

Some aspects to consider.

  • There's of course some cost to this.
  • As of Do not use assert for mesh orientation check #299, the element orientation check is no longer disabled by python -O.
  • Automatic flipping is only possible for volume meshes (AFAIK).
  • Orientation finding and flipping is only implemented for simplicial meshes ATM. This is important because any automatic feature breeds an expectation that it works unconditionally, on all types of meshes. It's not hard to fix this though.

@lukeolson @MTCam @anderson2981, opinions?

@MTCam
Copy link
Contributor

MTCam commented Mar 27, 2022

I wonder whether it might not be better to automatically fix the orientation of volume meshes coming in from gmsh.

👍 from my perspective. A nice fat warning would be nice: "Nice try, fool."

I think this has been true for at least a half a week already, right? Allowing a run to proceed that is using a mis-oriented mesh, imo should be disallowed. If a user wants to do this, they can monkey with it .. thy own self on YOYO time.

  • Orientation finding and flipping is only implemented for simplicial meshes ATM. This is important because any automatic feature breeds an expectation that it works unconditionally, on all types of meshes. It's not hard to fix this though.

This issue does not affect us atm, and we have no plans (or need) to use anything other than simplicial elements afaik. Other element types would be nice to have soon. We could mesh some boundary layer with long bricks, which might be nice, some day.

Overall, i'd say if you can fix this on-the-fly, then go for it. Save the users from themselves in this one case, not because they deserve it, but because it benefits me, us! i meant us!.

@lukeolson @MTCam @anderson2981, opinions?

@anderson2981
Copy link

I'm on board with a fix and a notification that it's being fixed, which allows the user to figure out why their mesh is wonky.

@lukeolson
Copy link
Collaborator

lukeolson commented Mar 28, 2022

Seems reasonable to either fail (and not proceed), or to fix the bad elements.

Meaning, if there's an assumption on mesh orientation and the mesh violates that, then it's an input error.

Is the fix simply to swap two vertices in the element list (for 2D or 3D simplex)?

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

No branches or pull requests

4 participants