Hey Matt,<br>    All I want to be able to do is generate plots of |r|/|r0| vs cpu time. I presumed that such information is commonly required when profiling the performance of solvers, so I thought it might be something you'd consider adding support for.<br>
<br>Cheers,<br>    Dave<br><br><br><div class="gmail_quote">On Fri, May 9, 2008 at 1:19 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div><div></div><div>On Thu, May 8, 2008 at 10:09 PM, Dave May <<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>> wrote:<br>
> Hey petsc folk,<br>
>     What is the best way to obtain timing information to profile the<br>
> performance<br>
> of KSPSolve (or SNESSolve)? Currently I have written some specific KSP<br>
> monitors,<br>
> but it I think it would be useful to have access to this information all the<br>
> time without<br>
>  having to go through the monitor. It seems like each object should know how<br>
> to time<br>
> some of its operations.<br>
><br>
> It would be very useful to have functions such as<br>
>   KSPGetCPUTime(KSP ksp,PetscLogDouble *time)<br>
>  to report the total solution time required by the KSPSolve() and<br>
>   KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na)<br>
> which is like KSPGetResidualHistory() but returns the accumulated cpu time<br>
> for each<br>
>  iterate<br>
><br>
> It would also be useful to have a default KSP monitor which could report the<br>
> time per iterate<br>
> or accumulate time. For example something like<br>
>   40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03<br>
>    41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02<br>
><br>
> Is there a better approach to what I've been doing and are there plans to<br>
> add any<br>
> additional features to help profile individual operations on each object?<br>
<br>
</div></div>Maybe you could motivate it by giving a use case? So far, I have never needed<br>
anything but the KSPSolve() event and stages to separately aggregate different<br>
types of solves.<br>
<br>
   Matt<br>
<br>
> Cheers,<br>
>     Dave<br>
<font color="#888888">--<br>
What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which<br>
their experiments lead.<br>
-- Norbert Wiener<br>
<br>
</font></blockquote></div><br>