Matthew Knepley <[email protected]> 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?

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