On Fri, Sep 6, 2013 at 2:26 PM, Peter Brune <[email protected]> wrote:
> > > > On Fri, Sep 6, 2013 at 1:53 PM, Matthew Knepley <[email protected]> wrote: > >> On Fri, Sep 6, 2013 at 1:33 PM, Jed Brown <[email protected]> wrote: >> >>> Please send these questions to petsc-dev (Cc'd now) or petsc-users so >>> that others can comment. >>> >>> Lulu Liu <[email protected]> writes: >>> >>> > Hi, >>> > >>> > I want to implement ASPIN-like ideas, but based on field splitting. You >>> > could find the details in PDF file. >>> >>> You are proposing left-preconditioned nonlinear additive fieldsplit. >>> This is a sensible algorithm that we have discussed before. The only >>> part that needs to be implemented is the fieldsplit solve: separation of >>> G and H, then solving each separately. >>> >>> Unfortunately, I think it's kinda tricky to come up with a generally >>> useful interface. In particular, many applications cannot partition the >>> variables like you have done, meaning that the preconditioner is >>> becomes: change variables, solve in other bases, then change back. At >>> this point, I would recommend implementing the solve with \hat F using >>> SNESShell. >>> >> >> Did we throw away the SNES 'multiblock' code? It was supposed to do this. >> >> > Multiblock never actually ran and therefore it has been removed from > compilation for some time. The code is still sitting there, though. We've > (Jed and I) been discussing how to put this together for some time and we > haven't settled on a model of prying apart the fields and field > residual/Jacobian assembly in such a way that makes this easy enough for > users to futz around with. We could easily do something akin to what we do > with (N)ASM and have hooks that spirit the whole solution to where the > evaluation needs it. > At one point it ran :) So I think the way to do this is to only activate it if the user has a DM+PetscSection. Then we have enough information to take apart the nonlinear residual evaluation. In fact, DMPlexComputeResidual() does it field-by-field right now. Matt > So, what do you do? Do you do whole-system residual evaluation followed > by restriction to the subsystem? Do you require the user to give you a > number of subproblems living on potentially different discretizations and > ways of gluing them together? These things need to be decided. > > ASPIN-like things with this would require having the outer solver know how > to pull apart the inner solver and get at its tasty, tasty fieldsplit > Jacobians. It would be a pretty easy extension of the preexisting ASPIN > stuff. > > - Peter > > Matt >> >> >>> > My questions: >>> > >>> > I have a nonlinear system including two equations. In my >>> implementation, I >>> > need to solve each equation separately, also I need to solve the >>> coupled >>> > system. I feel confused about ordering: >>> > >>> > I know the unknowns are ordered as [p1,s1,p2,s2,p3,s3,......] in PETSc, >>> > however, it seems that I need the variables like [p1,p2,p3,... >>> s1,s2,s3,...] >>> >>> No, just use a strided IS to describe each set of variables. You can >>> VecScatter from the packed/monolithic global vector to the split space. >>> >>> > Is there any example to do the similar things in PETSc? >>> > Do you have any ideas to implement the algorithm easier? >>> > How to quickly extract [p1,p2,...p_{N}] or [s1,s2,....] from >>> > [p1,p2,....s1,s2,s3,...] ? >>> > How to quickly get the composed [p1,p2,...s1,s2,....] if I have >>> [p1,p2,...] >>> > and [s1,s2,..]? >>> > >>> >>> >> >> >> -- >> 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 >> > > -- 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
