<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019 at 11:19 AM Zhang, Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div dir="ltr">
<div dir="ltr">
<div>Fande,</div>
<div>The images are very interesting and helpful. How did you get these images?</div></div></div></div></blockquote><div><br></div><div>We used gperftools <a href="https://gperftools.github.io/gperftools/heapprofile.html">https://gperftools.github.io/gperftools/heapprofile.html</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div dir="ltr">
<div><br>
</div>
<div>Petsc PtAP uses 753MB for PtAPSymbolic and only 116MB for PtAPNumeric, </div>
<div>while hypre uses 215MB -- it seems hypre does not implement symbolic PtAP.</div>
<div><br>
</div>
<div>When I implement PtAP, my focus was on numeric part because it was used repeatedly. Now we should look at symbolic part and optimize it. It should have room for improvement or new algorithmic approach.</div>
<div>We also need understand the algorithm and implementation used hypre. </div></div></div></div></blockquote><div><br></div><div>The reason PETSc PtAP uses a lot of memory is that the PETSc algorithm needs to create intermediate data such as AP_loc, P_loc, P_oth, Rd, Ro,  C_oth, etc. " -mat_freeintermediatedatastructures 1" does help reduce the memory usage  (see the attachment), but it is still twice more than that used in HYPRE PtAP.</div><div><br></div><div>The way to reduce the memory is to have the all-at-once algorithm (Mark is an expert on this). But I am not sure how efficient it could be implemented.   <br></div><div><br></div><div>Thanks,</div><div><br></div><div>Fande,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div dir="ltr">
<div><br>
</div>
<div>Hong</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Mar 21, 2019 at 6:37 PM Mark Adams via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Could you explain this more by adding some small examples?   </div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Since you are considering implementing all-at-once (four nested loops, right?) I'll give you my old code. </div>
<div><br>
</div>
<div>This code is hardwired for two AMG and for a geometric-AMG, where the blocks of the R (and hence P) matrices are scaled identities and I only store the scale. So you ignore those branches. This code also does equivalent real form complex, so more branches
 to ignore.</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>

</blockquote></div></div></div></div></div>