Segmentation fault in Trilinos direct solver

[yy.wayne]

In step-75 I try to replace the coarse mg solver with a direct solver, which is TrilinosWrappers::SolverDirect. However I get Segmentation error calling the direct solver, at the last step of SolverDirect::solve():

    solver_control.check(0,0);

 Where could be the mistake?  (The deal.ii version is 9.4.0)

[Marc Fehling]

Hello,

I can't identify the problem right away, but here are some tips in debugging it:

• Does the problem persist if you disable both h- and p-refinement? If so, than an issue might be that your data structures haven't been reinitialized after you updated your discretization.
• Do you run the code in Debug mode?
  
• Do you use the latest version of Trilinos?

Marc

[yy.wayne]

Thank for your reply,

 

Actually I just kill this error by writing the code again from scratch. I think the problem might be "system_matrix.clear()" is missed befor system_matrix.reinit().

[yy.wayne]

... sadly after some modification the errors show again(I adapt step-29 into this framework(involves FESystem), with matrix-based p-multigrid). I think the error is not on direct solver, since the coarse matrix is initialized successfully in Klu direct solver. However the worst thing is no error information is returned,  making it really difficult to debug. Maybe the problem is from transfer between MG levels? 

I'm runing on the 1.22 version deal.II virtualBox, so environment should be fine. 

Best,

Wayne

[yy.wayne]

Specifically, when a Trilinos::SolverDirect object calls solve(), the line 

        solver_control.check(0,0)

is not executed.

I've debuged with both QT and gdb but error information is similiar, both only returns a segmentation fault

[Wolfgang Bangerth]

On 10/11/22 23:19, 'yy.wayne' via deal.II User Group wrote:
> **

>
> Specifically, when a Trilinos::SolverDirect object calls solve(), the line
>
>         solver_control.check(0,0)
>
> is not executed.
> I've debuged with both QT and gdb but error information is similiar, both only
> returns a segmentation fault

Wayne:
I know nothing about the code in question, but have this advice:

The way to debug segmentation faults is to run the program in a debugger and
do two things:
* Take a look at the backtrace (=call stack) to know where you are when the
segfault happens
* In the debugger, go to the function where the problem happens and inspect
the local variables. A segfault means that you are accessing memory you are
not allowed to look at, and it is useful to know what variable it is you are
accessing. Typically, this is either an invalid array access, or derefencing
NULL or uninitialized pointers. You can often infer what happened if you know
what variable causes the invalid access.

I believe that I show something like this process in one of my video lectures,
but there are also certainly many other videos on youtube that show this
general procedure.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/