[petsc-dev] PCASM uses DMCreateDecomposition which splits field, NOT expected behavior

[Jed Brown]

On Mon, May 28, 2012 at 5:10 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

> On Mon, May 28, 2012 at 5:02 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> This is an enormous amount of new code and changes to put in during a
>> code freeze, but my test case works now.
>
> We can revert, if it starts causing problems.  The extra code is due to
> the API chance, hence several new interface functions.
>
>
>> A couple comments  from looking at the patch:
>>
>> I'm not sure I like the direction of the link in DMSetEmbedding(DM dm, IS
>> embedding, DM ambientdm). Normally the composite DM knows how to fit its
>> pieces together, but the sub-DM does not have "upward links" to the global
>> problem.
>>
> This is to be able to combine domain and field splits: sometimes a subDM
> has to know how to "relativize" itself with respect to another subDM.
>

I don't believe it has to. The current approach in PETSc has always been
that we store links going the other direction. I don't like the
inconsistency and I think the model is much more sustainable to hold
downward links only.

What algorithm can only be implemented with these upward links?


>
>> There are dead links in your documentation because you reference
>> functions that don't exist (were renamed), e.g. DMCreateDecomposition() in
>> the DMSetEmbedding() man page. There may be more. You should generate the
>> docs and check the man pages.
>>
>
>> How does your interface support "Neumann" subdomains?
>>
>
> I think this issue is orthogonal to the definition of the decomposition,
> since there has to be additional support at the PC
> and Mat level to assemble the Neumann subproblems.  At this point you
> would have to do some combination of PCASMSetModifySubmatrices() with
> nullspace removal.
>

Sure, you have to assemble to a different format, but what interface are we
going to use. In the linear case, we can, in principle, do everything with
matrices. For the nonlinear case, we need DM APIs. So in the nonlinear
context, how are we going to build Neumann problems?


> Your DMCreateDomainDecomposition() seems to provide nominally overlapping
>> index sets, but how do we determine what part is owned? (RASM, especially,
>> needs both an overlapping decomposition and a (non-overlapping) partition.
>>
> My intent was to have these be nonoverlapping and expand them with another
> call (e.g., DMDomainDecompositionIncreaseOverlap().
>

But with separate functions, we have to jump through extra hoops to use a
user-specified decomposition (e.g. that carefully selects Lagrange
multipliers or pressure variables to maintain inf-sup stability).


>  The current API plays better with GASM, since that PC assumes that the
> basic subdomains are nonoverlapping. That fix will have to wait for the
> next release, I guess.
>

PCGASMSetSubdomains() also has two IS arguments, so I don't know what you
mean.


We need to work out an interface for nonlinear DD (like ASPIN) this summer,
but I don't think it belongs in this release. I'm not so wild about putting
new interfaces into this release that will be changed immediately after.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120528/67d6de8f/attachment.html>