[petsc-users] Profiling/checkpoints

[Matthew Knepley]

On Tue, Aug 4, 2015 at 6:33 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> > On Aug 4, 2015, at 6:20 PM, Patrick Sanan <patrick.sanan at gmail.com>
> wrote:
> >
> > 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
>
>    You can also use the PETSc option -start_in_debugger which can work
> under some circumstances (like all MPI processes have access to the X
> server).


and you can start debuggers on only some processes using -debugger_nodes
1,3,7

  Thanks,

     Matt


>
>   Barry
>
> >
> >
> >> 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
> >>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20150804/9e22579a/attachment.html>