<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 12:13 PM 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>
> On Fri, Oct 26, 2018 at 11:24 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Fri, Oct 26, 2018 at 11:06 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
>> ><br>
>> >> 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<br>
>> 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.<br>
>> So<br>
>> >> 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<br>
>> >> 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>
>> >><br>
>> ><br>
>> > CreateSubDM() returns a DM whose DS only involves the subset of fields.<br>
>><br>
>> DS? That isn't really a DM-level concept; I see you use it in a couple<br>
>> utility functions in DMDA, but it isn't part of the solver-related<br>
>> functionality. In any case, the code you wrote above looks to be moving<br>
>> the outer ComputeOperators onto a sub-DM, which can't possibly be a<br>
>> desirable solution. Why can't DMCreateSubDM ensure that each sub DM is<br>
>> endowed with whatever discretization functionality is known?<br>
>><br>
><br>
> As I said in my reply, it already does this. HOWEVER, it cannot move the<br>
> construction functions from the old DMSNES to the subDMSNES, because it<br>
> does not know about SNES.<br>
<br>
DMSNES could register a callback to decompose itself for DMCreateSubDM.<br>
We do something similar in DMRestrictHook, for example.<br></blockquote><div><br></div><div>It looks like we will have to add a hook in order to break dependency cycles. I will</div><div>do it.</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">
Alternatively, the user could create the subDMs and endow them with<br>
functionality. You'd probably want DMGetSubDM for that since the parent<br>
DM would maintain ownership.<br>
<br>
>> > Thus, only<br>
>> > the v-v block is present in the subDM, and when the SNES assembly<br>
>> functions<br>
>> > is called,<br>
>> > it forms that block. I just need that function to be called.<br>
>><br>
>> Is it really the same function as is used by the outer DM?<br>
><br>
><br>
> Yes.<br>
><br>
> You are not addressing the question.<br>
<br>
I just wanted to clarify whether you thought that was something that<br>
could possibly be merged or just an attempted dirty hack.<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>