<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 14, 2015 at 8:14 AM, Koos Huijssen <span dir="ltr"><<a href="mailto:koos.huijssen@vortech.nl" target="_blank">koos.huijssen@vortech.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Dear Matt,<span class=""><br>
    <br>
    <div>On 14-9-2015 14:50, Matthew Knepley
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Mon, Sep 14, 2015 at 7:45 AM, Koos
            Huijssen <span dir="ltr"><<a href="mailto:koos.huijssen@vortech.nl" target="_blank">koos.huijssen@vortech.nl</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear
              PETSc development team,<br>
              <br>
              We have developed an extension of the PETSc event logging
              facilities that has the following advanced features:<br>
              <br>
              - It allows logging of events in the form of a nested
              tree. So if some function is called from multiple
              locations in the code, these instances are distinguished.
              This in contrast with the standard event logger, which
              only logs the amount of total call time.<br>
            </blockquote>
            <div><br>
            </div>
            <div>How is this different from using stages?</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Stages have to be set up explicitly, and there can only be 10
    stages. The nested event facility automatically provides a 'staged'
    appearance, as it keeps track of the whole tree of parent routines.
    As a user you don't have to bother about it, you just do your
    LogEventBegin - LogEventEnd and the rest is taken care by the
    system. Yet, the instrumentation is not heavy, so it doesn't
    introduce huge overhead in the code.</div></blockquote><div><br></div><div>Okay, so  this is automatic staging anytime an event is used in a different place in the call chain? That sounds nice. It</div><div>would be good if it could be overridden to identify events since sometimes the output can get complex.</div><div><br></div><div>  Thanks,</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""> <blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              - It allows the output report to be formatted in XML
              format. This output can then be viewed in a human-friendly
              form in a web browser<br>
               with the use of the XSL Transformation script
              performance_xml2html.xsl. The html features an nested
              timings tree that can be expanded and collapsed as
              desired.<br>
            </blockquote>
            <div><br>
            </div>
            <div>This sounds fine and useful. We will look at the code.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Great! Let me hear if you need further clarification.<br>
    <br>
    Kind regards,<br>
    <br>
    Koos<div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>  Thanks,</div>
            <div><br>
            </div>
            <div>     Matt</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              This tool has been very useful for us to analyze the code
              and pinpoint performance bottle necks. We think that it
              can be useful for others as well, and therefore we are
              providing the code here for integration in the open source
              distribution of PETSc.<br>
              <br>
              For more information I refer to the included manual. We
              have also provided a test program and a makefile for
              convenience. The test program can be run using MPI with
              for instance 3-6 processes.<br>
              <br>
              I apologize for not using the git repo to submit the
              developed code. I also apologize for not adhering to the
              PETSc coding standards (or at least not as far as I know),
              but I hope that it is not too far off.. Apart from the
              whole capital/underscore standardization stuff one issue
              may require special attention, namely the (ab)use of the
              format PETSc_VIEWER_ASCII_IMPL for signaling the XML
              format in XMLViewer.c. I couldn't find an already existing
              and better fitting format, but it could be necessary to
              add a new format here for this purpose.<br>
              <br>
              Can you take it up from here and realize the integration
              of the code in the PETSc distribution?<br>
              <br>
              With kind regards,<br>
              <br>
              Koos Huijssen<br>
              <br>
              -- <br>
____________________________________________________________________<br>
              <br>
              VORtech BV - Scientific software engineers<br>
____________________________________________________________________<br>
              <br>
              Dr.ir. Koos Huijssen<br>
              <br>
              P.O. Box 260<br>
              2600 AG Delft<br>
              The Netherlands<br>
              <br>
              phone  <a href="tel:%2B31%280%2915-285%200125" value="+31152850125" target="_blank">+31(0)15-285 0125</a><br>
              mobile <a href="tel:%2B31%280%296-3333%200803" value="+31633330803" target="_blank">+31(0)6-3333 0803</a><br>
              email <a href="mailto:koos.huijssen@vortech.nl" target="_blank">koos.huijssen@vortech.nl</a><br>
              web   <a href="http://www.vortech.nl" rel="noreferrer" target="_blank">www.vortech.nl</a><br>
____________________________________________________________________<br>
              <br>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div>What most experimenters take for
            granted before they begin their experiments is infinitely
            more interesting than any results to which their experiments
            lead.<br>
            -- Norbert Wiener</div>
        </div>
      </div>
    </blockquote>
    <br>
    <pre cols="72">-- 
____________________________________________________________________

VORtech BV - Scientific software engineers
____________________________________________________________________

Dr.ir. Koos Huijssen

P.O. Box 260
2600 AG Delft
The Netherlands

phone  <a href="tel:%2B31%280%2915-285%200125" value="+31152850125" target="_blank">+31(0)15-285 0125</a>
mobile +31(0)6-3333 0803
email <a href="mailto:koos.huijssen@vortech.nl" target="_blank">koos.huijssen@vortech.nl</a>
web   <a href="http://www.vortech.nl" target="_blank">www.vortech.nl</a>
____________________________________________________________________ </pre>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>