<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 11:24 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>
> 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 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<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></blockquote><div><br></div><div>As I said in my reply, it already does this. HOWEVER, it cannot move the</div><div>construction functions from the old DMSNES to the subDMSNES, because it</div><div>does not know about SNES.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Thus, only<br>
> the v-v block is present in the subDM, and when the SNES assembly 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?</blockquote><div><br></div><div>Yes.</div><div><br></div><div>You are not addressing the question.</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"> That is not<br>
a general-purpose solution because users can set<br>
DMKSPSetComputeOperators/KSPSetComputeOperator to directly call their<br>
own functions.<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>