<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 11:06 AM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
<br>
> I am having a problem, and every solution I can think of would seem to do<br>
> violence to encapsulation or to DMKSP/DMSNES.<br>
><br>
> I want to have GMG automatically work on the velocity part of Stokes. So I<br>
> give<br>
><br>
>   -fieldsplit_velocity_pc_type mg<br>
><br>
> in SNES ex62. This complains that the KSP has a DM but<br>
> KSPSetComputeOperator() has not been called. It is fine on the global<br>
> system because SNES called that in SNESSetupMatrices(). Thus in FieldSplit,<br>
> I inserted<br>
><br>
>           {<br>
>             PetscErrorCode (*func)(KSP,Mat,Mat,void*);<br>
>             void            *ctx;<br>
><br>
>             ierr = DMKSPGetComputeOperators(pc->dm, &func,<br>
> &ctx);CHKERRQ(ierr);<br>
>             ierr = DMKSPSetComputeOperators(dms[i],  func,<br>
> ctx);CHKERRQ(ierr);<br>
>           }<br>
<br>
Wait, pc->dm is the coupled system while each dms[i] is a component<br>
(like velocity).  It would be awkward to ask the user to write a single<br>
function that would inspect the DM to figure out what sort of problem it<br>
was discretizing (velocity-only, pressure-only,<br>
velocity-pressure-coupled, etc.).  Do you currently have a<br>
ComputeOperators for each sub-problem?<br></blockquote><div><br></div><div>CreateSubDM() returns a DM whose DS only involves the subset of fields. Thus, only</div><div>the v-v block is present in the subDM, and when the SNES assembly functions is called,</div><div>it forms that block. I just need that function to be called.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> where we call KSPSetDM(). However, this does not work, because the subDM<br>
> has a new DMSNES, which does not have the information about the problem.<br>
><br>
> Solution #1:<br>
><br>
>   Copy the info from the old DMSNES to the subDMSNES. This inserts a<br>
> dependence between KSP and SNES which we do not want.<br>
><br>
> Solution #2:<br>
><br>
>   Have DMCreateSubDM() copy everything from the solvers. This also inserts<br>
> dependencies, unless we have a "copy everything" mechanism, but is this<br>
> what we want.<br>
><br>
> Solution #3:<br>
><br>
>   Rethink DMKSP/DMSNES. Is this how we should store problem information.<br>
> Dave already had another problem with the organization.<br>
><br>
> What should be done? I have never understood this construct very well.<br>
> Right now, this is holding up doing some computations I need.<br>
><br>
>   Thanks,<br>
><br>
>      Matt<br>
> -- <br>
> What most experimenters take for granted before they begin their<br>
> experiments is infinitely more interesting than any results to which their<br>
> experiments lead.<br>
> -- Norbert Wiener<br>
><br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a> <<a href="http://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">http://www.cse.buffalo.edu/~knepley/</a>><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>