[petsc-dev] PCFieldSplitSetFields() API change

[Barry Smith]

On Jun 6, 2012, at 5:16 PM, Dmitry Karpeev wrote:

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

    No you don't get back a pair of subDMS, you get a DM that goes from one state space to "a different" residual space. Normally one would not need this though it does come up in the VI stuff.

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

    I am not sure if this will be right in the long run; it need not be square (for example least squares solve?).

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

   Just like MatGetVecs() actually returns left and right vectors we may need to change DM to return left and right vecs.

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

   Actually RASM has an option where the output space is larger than the input space. (The subproblems are defined as extending the right hand side by zero, solving the subproblem and then keeping the entire solution (on the overlapped region).

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