[petsc-dev] Problem with DMKSP/DMSNES and GMG

Jed Brown jed at jedbrown.org
Fri Oct 26 11:13:06 CDT 2018


Matthew Knepley <knepley at gmail.com> writes:

> On Fri, Oct 26, 2018 at 11:24 AM Jed Brown <jed at jedbrown.org> wrote:
>
>> Matthew Knepley <knepley at gmail.com> writes:
>>
>> > On Fri, Oct 26, 2018 at 11:06 AM Jed Brown <jed at jedbrown.org> wrote:
>> >
>> >> Matthew Knepley <knepley at gmail.com> writes:
>> >>
>> >> > I am having a problem, and every solution I can think of would seem
>> to do
>> >> > violence to encapsulation or to DMKSP/DMSNES.
>> >> >
>> >> > I want to have GMG automatically work on the velocity part of Stokes.
>> So
>> >> I
>> >> > give
>> >> >
>> >> >   -fieldsplit_velocity_pc_type mg
>> >> >
>> >> > in SNES ex62. This complains that the KSP has a DM but
>> >> > KSPSetComputeOperator() has not been called. It is fine on the global
>> >> > system because SNES called that in SNESSetupMatrices(). Thus in
>> >> FieldSplit,
>> >> > I inserted
>> >> >
>> >> >           {
>> >> >             PetscErrorCode (*func)(KSP,Mat,Mat,void*);
>> >> >             void            *ctx;
>> >> >
>> >> >             ierr = DMKSPGetComputeOperators(pc->dm, &func,
>> >> > &ctx);CHKERRQ(ierr);
>> >> >             ierr = DMKSPSetComputeOperators(dms[i],  func,
>> >> > ctx);CHKERRQ(ierr);
>> >> >           }
>> >>
>> >> Wait, pc->dm is the coupled system while each dms[i] is a component
>> >> (like velocity).  It would be awkward to ask the user to write a single
>> >> function that would inspect the DM to figure out what sort of problem it
>> >> was discretizing (velocity-only, pressure-only,
>> >> velocity-pressure-coupled, etc.).  Do you currently have a
>> >> ComputeOperators for each sub-problem?
>> >>
>> >
>> > CreateSubDM() returns a DM whose DS only involves the subset of fields.
>>
>> DS?  That isn't really a DM-level concept; I see you use it in a couple
>> utility functions in DMDA, but it isn't part of the solver-related
>> functionality.  In any case, the code you wrote above looks to be moving
>> the outer ComputeOperators onto a sub-DM, which can't possibly be a
>> desirable solution.  Why can't DMCreateSubDM ensure that each sub DM is
>> endowed with whatever discretization functionality is known?
>>
>
> As I said in my reply, it already does this. HOWEVER, it cannot move the
> construction functions from the old DMSNES to the subDMSNES, because it
> does not know about SNES.

DMSNES could register a callback to decompose itself for DMCreateSubDM.
We do something similar in DMRestrictHook, for example.

Alternatively, the user could create the subDMs and endow them with
functionality.  You'd probably want DMGetSubDM for that since the parent
DM would maintain ownership.

>> > Thus, only
>> > the v-v block is present in the subDM, and when the SNES assembly
>> functions
>> > is called,
>> > it forms that block. I just need that function to be called.
>>
>> Is it really the same function as is used by the outer DM?
>
>
> Yes.
>
> You are not addressing the question.

I just wanted to clarify whether you thought that was something that
could possibly be merged or just an attempted dirty hack.


More information about the petsc-dev mailing list