On Wed, Jun 6, 2012 at 4:58 PM, Jed Brown <[email protected]> wrote:

On Fri, Mar 23, 2012 at 10:15 PM, Barry Smith <[email protected]> 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.