[petsc-dev] asm / gasm

[Mark Adams]

Thanks Barry, ... we are still not communicating (see below).

On Sun, Jun 26, 2016 at 11:56 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   I have changed the GAMG aggs support to use PCASM and not PCGASM. I
> don't see how it ever worked with PCGASM; very strange. Maybe it was
> written and tested with PCASM and then later someone changed to PCGASM and
> did not test it again.
>

I really thought it was ASM but memory can be strange sometimes ...


>
>   I was wrong when I said it would be difficult to change to PCASM, it was
> much simpler to change to PCASM then I thought; this is because I assumed
> it had been done correctly for PCGASM while in fact though it used PCGASM
> in the code it followed the model for what PCASM needed :-(.
>
>    Anyways I have a branch barry/fix-gamg-asm-aggs that now works for my
> ex10 tests  I will continue to clean up the branch, fixing naming styles
> and test with more difficult GAMG examples. And add proper nightly tests
> for this functionality which it never had before.
>

Great thanks.

Which ex10 is it?  and how to I run your tests?

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.


>
>    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.
>
>    Barry
>
>
> 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.


NO, NO, NO


> This is exactly what PCASM needs but NOT what PCGASM needs.
>
>
My aggregates span processor subdomains.

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.)

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.

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.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160627/60e5c91e/attachment.html>