[petsc-users] Profiling/checkpoints

[Patrick Sanan]

And note that it is possible to run gdb/lldb on each of several MPI processes, useful when you hit a bug that only appears in parallel.  For example, this FAQ describes a couple of ways to do this:

https://www.open-mpi.org/faq/?category=debugging#serial-debuggers


> Am 05.08.2015 um 00:36 schrieb Barry Smith <bsmith at mcs.anl.gov>:
> 
> 
>  Correction, even in parallel you should be able to use a 0 for the viewer for calls to KSPView() etc; just make sure you do the same call on each process that shares the object. 
> 
>   To change the viewer format you do need to use PetscViewerSetFormat(PETSC_VIEWER_STDOUT_(PETSC_COMM_WORLD), PETSC_VIEWER_ASCII_INFO)  to change the format for parallel objects that live on PETSC_COMM_WORLD.
> 
> 
>  Barry
> 
> PetscViewerSetFormat(0, PETSC_VIEWER_ASCII_INFO) only effects the format of the sequential ASCII viewer.
> 
>> On Aug 4, 2015, at 5:22 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> 
>> 
>> I do this by running in the debugger and putting in breakpoints. At the breakpoint you can look directly at variables like the n in call to VecMDot() you can also call KSPView() etc on any PETSc object (with a viewer of 0) and it will print out the information about the object right then. Calling VecView() or MatView() directly will of course cause it to print the entire object which generally you don't want but you can do PetscViewerSetFormat(0, PETSC_VIEWER_ASCII_INFO) and then VecView or MatView to have it print size information etc about the object instead of the full object. In parallel instead of passing 0 for the viewer you need to pass PETSC_VIEWER_STDOUT_(PETSC_COMM_WORLD) and make sure all processes that share the object call the routine in the debugger but it is possible.
>> 
>> Let us know how it goes and we can try to improve the experience with your suggestions,
>> 
>> Barry
>> 
>>> On Aug 4, 2015, at 5:09 PM, Justin Chang <jychang48 at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Not sure what to title this mail, but let me begin with an analogy of what I am looking for:
>>> 
>>> In MATLAB, we could insert breakpoints into the code, such that when we run the program, we could pause the execution and see what the variables contain and what is going on exactly within your function calls. Is there a way to do something like this within PETSc?
>>> 
>>> I want to see what's going on within certain PETSc functions within KSPSolve. For instance, -log_summary says that my solver invokes calls to functions like VecMDot and VecMAXPY but I would like to know exactly how many vectors each of these functions are working with. Morever, I would also like to get a general overview of the properties of the matrices MatPtAP and MatMatMult are playing with (e.g., dimensions, number of nonzeros, etc).
>>> 
>>> Or
>>> 
>>> Above functions happen to be invoked from gamg, so is it possible to tell just from the parameters fed into PETSc what the answers to the above may be?
>>> 
>>> Thanks,
>>> Justin
>