-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments
👍 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.
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
|
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. |
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)? |
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.
assert
for mesh orientation check #299, the element orientation check is no longer disabled bypython -O
.@lukeolson @MTCam @anderson2981, opinions?
The text was updated successfully, but these errors were encountered: