*If you run the program in a debugger, can you find out where the segfault happens?*
Yes, the starting point of the trace is "TrilinosWrappers::SolverDirect::do_solve", and the segmentation fault occurs in the libsuperlu_dist library. On reviewing the do_solve function, it seems the exception TrilinosWrappers::SolverDirect::ExcTrilinosError is expected to be thrown. While Amesos_Mumps solver correctly throws this exception, unfortunately, Amesos_superludist does not. :( As you mentioned, it might be worthwhile to try a newer version of deal.II, which provides wrappers for the more advanced Amesos2 and Tpetra packages. *Perhaps a better approach than seeing whether a linear solver succeeds would be to first check whether the matrix/rhs have NaNs before you hand them off to the solver. * My motivation for avoiding such checks was to keep the optimized release code free of unnecessary overhead, trusting that the solver would throw appropriate exceptions when feeded with bad input. However, I probably can not rely on that for all solvers, and manually checking for NaN is the more reliable approach. -Simon On Wednesday, December 18, 2024 at 11:53:42 PM UTC+1 Wolfgang Bangerth wrote: Simon: > Unfortunately, the program results in a segmentation fault. Specifically, no > exception (TrilinosWrappers::SolverDirect::ExcTrilinosError) is thrown when > the matrix containing NaN values is passed to the solver's solve function. If you run the program in a debugger, can you find out where the segfault happens? > In contrast, when running a sequential program with SparseDirectUMFPACK, the > solver correctly handles the issue, and I am able to catch the exception > SparseDirectUMFPACK::ExcUMFPACKError. > > Can this be considered a Trilinos bug? Has this issue been addressed in newer > versions of deal.II or Trilinos? Segfaults should never happen. Better error messages are always better, but I don't know whether this has been addressed. Perhaps this is your chance to try a newer version of deal.II? ;-) > Clearly, assigning NaN values to a matrix does not make much sense. However, > in the optimized release version of my program, bad inputs can occasionally > lead to cases where the cell matrix contains NaN values. In such situations, I > rely on catching exceptions (e.g., from SparseDirectUMFPACK) to handle the > error gracefully. Perhaps a better approach than seeing whether a linear solver succeeds would be to first check whether the matrix/rhs have NaNs before you hand them off to the solver. This can be done cheaply via the Vector::l1_norm() and SparseMatrix::frobenius_norm() functions that simply add up the (squares) or entries. If the result is NaN, you know something is amiss. Best W. -- ------------------------------------------------------------------------ Wolfgang Bangerth email: bang...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/dealii/cecde726-6a28-4a14-95c9-395c19250a26n%40googlegroups.com.
