deal.II dynamic assert doesn't terminate coupled simulation

[davidscn]

There are various options to raise an exception in deal.II, and they always use the Assert or AssertThrow mechansim. The Assert macro is a debug assert and uses the std::abort mechanism (see here) whereas the AssertThrow mechanism is used for dynamic error checking throws the exception normally. The abort assert mechanism works well, but the dynamic mechanism does not. The asserted participant terminates the calculation and preCICE prints:

---[precice]  Implicitly finalizing in destructor

but no message and no stacktrace is printed on the screen, the asserted participant hangs at this point (not terminated), and other participants keep waiting for response. That's in particular a problem if you run your cases on a cluster and you don't get any information about your failed simulation. Apart from that, the missing message and the missing stacktrace is a problem for user.
Hence, I guess there is some clash with preCICE internals. I don't really understand the behavior at the moment. I'm using deal.II 9.3.0-pre and precice2.1.1.

It's also worth noting that the Assertmechanism doesn't trigger the preCICE destructor as shown above. I think preCICE catches the usual throw somehow so it might be related to a preCICE change where we added the implicit finalization.

Maybe @fsimonis has an idea about this.

[fsimonis]

preCICE finalizes its internals in 2 cases:

1. explicitly by calling finalize()
2. implicitly on destruction of the SolverInterface in case it was not explicitly finalized before.

Throwing an exception in cpp results in stack unwind. Which calls the descructors of previously constructed objects until the exception is caught, hence also the destructor of the SolverInterface. The interface then tries to finalize, which does not match the control flow of the coupled participant. As you observed, both participants most likely hang in this scenario.

Calling std::abort() in contrast does not unwind the stack and results in a "hard crash". The other solver then likely crashes due to a closed/reset communication channel.

[davidscn]

mhm That's a very nice description. However, a solution would be very helpful in terms of usability since AsserThrow is the deal.II standard macro for exception handling in a release build (C++ as well AFAIK) and it cannot be assumed that someone is observing the simulation progress all the time.