[petsc-dev] PCFieldSplitSetFields() API change

[Dmitry Karpeev]

On Wed, Jun 6, 2012 at 4:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Fri, Mar 23, 2012 at 10:15 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>
>> On Mar 23, 2012, at 6:22 PM, Jed Brown wrote:
>>
>> > But what does using B as 00 block actually mean? It seems to me that
>> you pivot, producing P' P J where P J has B in the 00 location.
>>
>>    I am not arguing if it is pivoting or not. I'm arguing what the user
>> interface should be.  Say I want D to be the 00 block then I just set that
>> with PCFieldSplitSetFields() as the zeroth field. My point is that I am
>> proposing a SINGLE interface for setting the blocks locations in all
>> circumstances, while you are proposing having an additional interface for
>> certain 00 configurations (pivoting) thus with your model you first call
>> the PCFieldSplitSetFields() and then something else.
>
>
> I just talked about this more with Dmitry.
>
> It seems that we need to name both the row and column spaces of the
> operator.
>
The reason is that we need to be able to address the subproblem (e.g., from
the command-line to dial its solver options), not the individual row
(output) or col (input) fields.  And a subproblem, by definition, involves
an input-output (col-row) pair.
Further, if we wanted to recursively split/domain-decompose/coarsen the
subproblem, we might want to associate a subDM with it.  If we associated
subDMs with each row and col split, a subproblem would end up with a pair
of subDMs, which wouldn't be all that useful.


> Which begs the question: what is DM? Is it a distribution of the state
> space (column space for a linear operator), a distribution of the residual
> space (row space), or both? If both, we should make it possible to select
> arbitrary pairs.
>
A DM, in my view, should a "(sub)problem", which can be solved, hence,
implicitly, is square. Further, as currently implemented, a DM uses the
same distribution for solutions and residuals (since there is only one
DMCreateGlobalVector()).  This actually works for PCFieldSplit, because the
implied meaning of a field split is a nodewise split of the degrees of
freedom over some background mesh, with the distribution of nodes
determining the dof distribution.
The reason this works for PCASM is that we demand that the input/output
spaces are nested (e.g., the output space for RASM is a subspace of the
input).  I don't know whether we want to generalize away from it.  Even
within the current DM model it defines a subproblem that can be used in
FieldSplit and ASM.  All we have to do, if we are to stick with this, is
make sure that the local sizes match for the ISs in the pair defining a
subproblem.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120606/edd54d79/attachment.html>