<div dir="ltr">ML and Hypre both use RAP, as I recall.<div><br></div><div>PtAP uses outer product which cannot be as fast as RAP, based on an analysis of memory access. </div><div><br></div><div>Sequential RARt might be fast if ARt has small number of colors. We do not have parallel RARt.</div><div><br></div><div>Hong<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 9:47 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
> On Feb 23, 2015, at 9:41 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
> Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
>>   Freeze the hierarchy and coarse grid interpolations of GAMG but<br>
>>   compute the new coarse grid operators RAP for each new linear<br>
>>   system (this is a much cheaper operation). Use<br>
>>   PCGAMGSetReuseInterpolation() to freeze/unfreeze the hierarchy.<br>
><br>
> The RAP is often more than 50% of PCSetUp, so this might not save much.<br>
<br>
</div></div>   Hee,hee  in some of my recent runs of GAMG the RAP was less than 25% of the time. Thus skipping the other portions could really pay off.*<br>
<br>
  Barry<br>
<br>
* this could just be because the RAP portion has been optimized much more than the other parts but ...<br>
<br>
<br>
</blockquote></div><br></div></div></div>