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

[Matthew Knepley]

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

   Matt


> > where we call KSPSetDM(). However, this does not work, because the subDM
> > has a new DMSNES, which does not have the information about the problem.
> >
> > Solution #1:
> >
> >   Copy the info from the old DMSNES to the subDMSNES. This inserts a
> > dependence between KSP and SNES which we do not want.
> >
> > Solution #2:
> >
> >   Have DMCreateSubDM() copy everything from the solvers. This also
> inserts
> > dependencies, unless we have a "copy everything" mechanism, but is this
> > what we want.
> >
> > Solution #3:
> >
> >   Rethink DMKSP/DMSNES. Is this how we should store problem information.
> > Dave already had another problem with the organization.
> >
> > What should be done? I have never understood this construct very well.
> > Right now, this is holding up doing some computations I need.
> >
> >   Thanks,
> >
> >      Matt
> > --
> > 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
> >
> > https://www.cse.buffalo.edu/~knepley/ <
> http://www.cse.buffalo.edu/~knepley/>
>


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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20181026/84fb4a46/attachment.html>