<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Garth: we have something for you to try: branch <span style="font-size:12.8px">barry/fix-gamg-asm-aggs</span></div><div><br></div><div>add: -pc_gamg_use_agg_asm -mg_levels_sub_pc_type lu </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">><br>
> I added some code to add a block on each processor for any singletons, because the MIS code strips these (so, yes, not a true MIS).  I should do this for users that put a live equation in a singleton, like a non-homo Diri BC.  I can add that you your branch.  Let me know if that is OK.<br>
<br>
</span>   I do not understand this. Do you mean a variable that is only coupled to itself? So the row and column for the variable have only an entry on the diagonal? </blockquote><div><br></div><div>Yes, a BC that has not been removed from the matrix.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Or only the rows have an entry on the diagonal? What do you mean "strips it out"? Do you mean it appears in NO aggregate with MIS?<br>
<br></blockquote><div><br></div><div>Yes, because I don't want these as coarse grid variables. They do not need a coarse grid correction. An app can have millions of these and I don't want them around (eg, they are low rank when you have more null space vectors than block size)</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  Rather than "adding a block on each processor for singletons won't it be better that MIS doesn't "strip these out" but instead puts them each in their own little (size 1) aggregate? Then they will automatically get their own blocks?<br></blockquote><div><br></div><div>I would then have to strip them out again for the prolongator and having a full blown ASM block for every BC vertex would be a mess.  I just prefer to strip them out.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class="">><br>
><br>
>    In addition Fande is adding error checking to PCGASM so if you pass it badly formatted subdomain information (like was passed from GAMG) it will generate a very useful error message instead of just chugging along with gibberish.<br>
><br>
>    Barry<br>
><br>
><br>
> Mark, my confusion came from that fact that  a single MPI process owns each of the aggs; that is the list of degrees of freedom for each agg is all on one process.<br>
><br>
> NO, NO, NO<br>
><br>
> This is exactly what PCASM needs but NOT what PCGASM needs.<br>
><br>
><br>
> My aggregates span processor subdomains.<br>
><br>
> The MIS aggregator is such (simple greedy) that an aggregate assigned to a process can span only one layer of vertices into a neighbor. (The HEM coarsener is more sophisticated and can deal with Jed's canonical thin wire, for instance, and can span forever, sort of.)<br>
><br>
> So the code now is giving you aggregates that span processors (ie, not local indices).  I am puzzled that this works.  Am I misunderstanding you? You are very clear here. Puzzled.<br>
<br>
</span>  I mean that ALL the indices for any single aggregate are ALL stored on the same process; in the same aggregate list! I don't mean that the indices for an aggregate can only be for variables that live on that process.  I think we are in understanding here, just bad communication.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div> </div><div>OK, good.</div><div><br></div><div>I will add the fix for BCs and add this to ksp/ex56 and test it.<br></div><div><br></div><div>Thanks,</div><div>Mark</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
<br>
<br>
><br>
> I can change this, if ASM can not deal with this. I will just drop off-processor indices and add non-covered indices to my new singleton aggregate.<br>
><br>
> Mark<br>
<br>
</div></div></blockquote></div><br></div></div>