You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The meshpy error processing is a bit too sensitive in that it simply scans for the word 'error' in the stderr of the gmsh output (https://github.com/inducer/meshpy/blob/master/meshpy/gmsh.py#L182). This is problematic if some warning occurs during the gmsh run, which typically leads to output like this:
Warning : ------------------------------
Warning : Mesh generation error summary
Warning : 6 warnings
Warning : 0 errors
Warning : Check the full log for details
Warning : ------------------------------
Clearly, there was no error, but meshpy still throws a GmshError.
The text was updated successfully, but these errors were encountered:
I'm open to taking a patch to introduce an option like break_on_warning=True. (i.e. defaulting to true to match current behavior) I'm not sure how one could determine whether an error or a warning occurred--I'm not too fond of parsing the gmsh output, but I suppose that could be done. Another aspect is that I've found that meshes that come out with warnings are most often pretty much unusable--so, at least in part, this behavior is there by design.
The meshpy error processing is a bit too sensitive in that it simply scans for the word 'error' in the stderr of the gmsh output (https://github.com/inducer/meshpy/blob/master/meshpy/gmsh.py#L182). This is problematic if some warning occurs during the gmsh run, which typically leads to output like this:
Clearly, there was no error, but meshpy still throws a
GmshError
.The text was updated successfully, but these errors were encountered: