More and/or better use of libMesh exception types

[permcody]

We have a need to catch the "negative Jacobian" exceptions being thrown from libMesh. Right now nearly all exceptions in libMesh are of type LogicError including this one. I'd prefer to catch a few different types of errors rather than all LogicErrors, many of which are truly unrecoverable. For now, I might choose to look at what() to handle only the exception I'd like but additional types or correct usage of the existing types could be improved in the library.

[friedmud]

Whatever happened to this? Were you ever able to reproduce it?

[permcody]

This particular issue isn't an error. It's an enhancement to have better Exception types. I believe you are curious about the Negative Jacobian exception handling I was attempting to build into MOOSE. The answer is no, I haven't worked on it since the tiger team. I'll see if @jwpeterson is interested. I can give him my PR with the input file in the proposed change to MOOSE or he can start from scratch. I suspect it'll be a very small change on our (MOOSE) side.

[jwpeterson]

I'll see if @jwpeterson is interesting.

I'm the most interesting man in the world.

[permcody]

Well it looks like I forgot to commit the input file I generated when I was working on this problem! Only the logic that I was hoping would work in this case is intact so you'll have to make a new input file. What I did was just apply a displacement based on an AuxVariable that was a simple function of location (my mesh was carefully placed so that only one node was affected by the function). Everything else in that input file was pretty much stock simple_transient_diffusion. The try/catch logic I was working on is here: https://github.com/permcody/moose/tree/moose_exception_reinit

[bwspenc]

@permcody Have you done any more with this recently? We are running some models where we are getting bit by failures due to negative Jacobians, and we'd love to handle them by cutting the time step. We started going down a similar path to what you were doing in your MOOSE branch, and I was just curious if there were any insights you might have from looking at this you could share about this to help us implement that.

[permcody]

I haven't had any time to look at this since the Tiger Team. I do think it's really important and I'm happy to help assist with anyone willing to work on it. Personally what I'd like to see is different exception types thrown from libMesh so that we can catch certain types and handle them starting with this negative Jacobian error. Let's start by creating a small input file that actually reliably gives us a negative Jacobian error. If you were there, I was unable to do this in the Tiger team even after completely inverting the element I was working with!

After that I propose we bring in @jwpeterson or @roystgnr to discuss ideas or ways of throwing different exception types at the libMesh level. Ideally we can catch some NegativeJacobianError() type in application code and do something intelligent with it like cut the timestep.

[bwspenc]

I had the same issue with getting an element to invert. I was shocked to see that when I turned the element completely inside out it didn't invert, which is a separate issue that needs to be investigated. I do have a single element test case that does invert, but it's a little squirrely and I kind of doubt that it will reliably work on all platforms or anything. I agree that it would be good if libMesh threw a different exception type (what this issue is for), but I'd like to just get this working with the logicError first.

[roystgnr]

My first impulse is to subclass the existing exceptions. NegativeJacobianError would be a subclass of ConvergenceFailure, for instance, when talking about formulation Jacobians.

In the context of element master->physical space Jacobians, on the other hand, there's more room for debate. If I'd been extending things myself I'd have made a ElementError subclass of LogicError, but if we need to support inside-out elements then that needs to not be an error at all.

[permcody]

@roystgnr - this sounds good to me. I don't think there's any problem with adding as many new types as are necessary. Then we can start catching specific types. I don't have any strong opinions on the hierarchy that's defined, as long as it makes sense to someone 😄 .