Open inducer opened 2 years ago
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."
- 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 bypython -O
.
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?
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 https://github.com/illinois-ceesd/drivers_y2-isolator/issues/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.
python -O
.@lukeolson @mtcam @anderson2981, opinions?