On Mon, Dec 2, 2013 at 9:47 AM, Lawrence Mitchell < [email protected]> wrote:
> > On 2 Dec 2013, at 15:20, Matthew Knepley <[email protected]> wrote: > > > On Mon, Dec 2, 2013 at 6:31 AM, Lawrence Mitchell < > [email protected]> wrote: > > > > On 2 Dec 2013, at 12:23, Matthew Knepley <[email protected]> wrote: > > > > > On Mon, Dec 2, 2013 at 2:26 AM, Lawrence Mitchell < > [email protected]> wrote: > > > Dear petsc-users, > > > > > > I have a 3x3 block system built as a single MatNest (with 9 Mats in > it). I'd like to treat this as a 2x2 system: > > > [ A B > > > C D ] > > > > > > where A is 2x2 and precondition the A block with a schur complement. > Since I have a mat nest, the ISes for the three fields are just > ISCreateStride(..., mat_i_rows, offset, 1, ...) and these are set on the > fieldsplit pc. If I understand the documentation correctly, I think I > should now be able to do: > > > > > > -pc_type fieldsplit -fieldsplit_0_fields 0,1 -fieldsplit_1_fields 2 > -fieldsplit_0_pc_type field split -fieldsplit_0_pc_fieldsplit_type schur > > > > > > ... > > > > > > However, when doing so, I get an error: "To use Schur complement > preconditioner you must have exactly 2 fields". Which suggests to me I > have failed to inform PETSc that I want the first two fields to be treated > as 1. > > > > > > Note that I am not using a DM to build any of these objects. I build > a SNES, pull the KSP out of the SNES and then the PC out of the KSP. I > never explicitly call SetFromOptions on the PC. Instead, before the SNES > solve I call SNESSetFromOptions. Might this be the problem? > > > > > > This is an unfortunately limitation of the implementation right now. > This option works if you are on a DA with collocation, or if you > > > use a DM, but not if you just specify the ISes. We should probably > write that code. However, the idea is for people to be moving > > > to using DM. Could you tell us why DM did not work for you here? > > > > At the moment, our mesh infrastructure is not plumbed in to use petsc > data structures. We're attempting to migrate to dmplex at the moment but > currently we're building Mats from third-party connectivity information. > It's possible that the move to dmplex will happen soon enough that it > isn't a big issue, but I don't know the timescales on which we'll be done > with that. > > > > I was feeling bad about not implementing this, but I remembered the > problem with the pure IS solution. The obvious solution > > is to just combine several ISes to create the field for PCFIELDSPLIT. > However, once this is done, they lose their identity as > > separate fields. Thus, it is not possible to untangle for the second > level of FieldSplit that you want. The DM version maintains > > the field identity at the next level so that we can split > hierarchically. So, for the above to work, I think you must use a DM. > > OK, I think I see. I wonder if, until I have a DM in place, I can hack > this together by building my MatNest recursively? That is build > > A = [A' B' > C' D'] > > and then build > > F = [A B > C D] > > would that work, or am I barking up the wrong tree? > MatNest is only an optimization. It makes no-copy extraction of submatrices feasible. It is not an interface, and thus does not tell FieldSplit anything. Everything you can do with MatNest you can do without it. Matt > Cheers, > > Lawrence > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
