<div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 21, 2019 at 10:18 AM Lawrence Mitchell via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear petsc-dev,<br>
<br>
95dbaa6faf01fdfd99114b7c9e5668e4b2aa754d<br>
<br>
which does this:<br>
<br>
commit 95dbaa6faf01fdfd99114b7c9e5668e4b2aa754d<br>
Author: Matthew G. Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>><br>
Date:   Fri Oct 26 14:12:14 2018 -0400<br>
<br>
    PC: FieldSplit must copy DMKSP routines to subDM<br>
<br>
diff --git a/src/ksp/pc/impls/fieldsplit/fieldsplit.c b/src/ksp/pc/impls/fieldsplit/fieldsplit.c<br>
index b6a84ea342..f43f831204 100644<br>
--- a/src/ksp/pc/impls/fieldsplit/fieldsplit.c<br>
+++ b/src/ksp/pc/impls/fieldsplit/fieldsplit.c<br>
@@ -386,6 +386,13 @@ static PetscErrorCode PCFieldSplitSetDefaults(PC pc)<br>
           ierr = PetscObjectSetOptionsPrefix((PetscObject)(dms[i]), prefix);CHKERRQ(ierr);<br>
           ierr = KSPSetDM(ilink->ksp, dms[i]);CHKERRQ(ierr);<br>
           ierr = KSPSetDMActive(ilink->ksp, PETSC_FALSE);CHKERRQ(ierr);<br>
+          {<br>
+            PetscErrorCode (*func)(KSP,Mat,Mat,void*);<br>
+            void            *ctx;<br>
+<br>
+            ierr = DMKSPGetComputeOperators(pc->dm, &func, &ctx);CHKERRQ(ierr);<br>
+            ierr = DMKSPSetComputeOperators(dms[i],  func,  ctx);CHKERRQ(ierr);<br>
+          }<br>
           ierr = PetscObjectIncrementTabLevel((PetscObject)dms[i],(PetscObject)ilink->ksp,0);CHKERRQ<br>
           ierr = DMDestroy(&dms[i]);CHKERRQ(ierr);<br>
         }<br>
<br>
Breaks many uses of PCMG and fieldsplit for us.<br>
<br>
I would like to try and understand how best to fix it. My understanding of the way this stuff works is that when I say:<br>
<br>
KSPSetComputeOperators<br>
<br>
I provide a callback function (which I control), and some user-defined context (which I also control).<br>
<br>
What this code is doing (which previously it did not), is to transfer this callback and context inside PCFieldsplit from a DM defining the full problem onto a DM from DMCreateFieldDecomposition (i.e. only part of the problem).<br>
<br>
This seems like it is tremendously fragile, because PETSc has no way of knowing that the context for the full DM (which is just a void *) is valid for the subdm. In particular, in my case, I think it turns out not to be.<br></blockquote><div><br></div><div>Here is why I did this. I wanted this to work</div><div><br></div><div>  <a href="https://bitbucket.org/petsc/petsc/src/4dbc1805575afffed4e440f1353fcfccbc893081/src/snes/examples/tutorials/ex62.c#lines-1062">https://bitbucket.org/petsc/petsc/src/4dbc1805575afffed4e440f1353fcfccbc893081/src/snes/examples/tutorials/ex62.c#lines-1062</a></div><div><br></div><div>The DMKSP is initialized by SNES to have a function which says "get your matrix from SNES". Without this, the subproblem could</div><div>not make the matrix. Now I changed the description of exactly what matrix it is making and stored that in the subDM.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What is the right way to think about fixing this? I think that if the DM can create a field decomposition, it should also be able to transfer user callbacks from the parent to the subdms.<br>
<br>
That way, the DM (IOW me) can control how that happens.<br></blockquote><div><br></div><div>Yes, that is what I thought I was doing above. Preserving the callbacks that had been set in the original DM.</div><div>Maybe clarify what you think should happen.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or do I have the way this is supposed to work all wrong. Is the ComputeOperators callback I set meant to be completely agnostic, and it should get all the problem-specific information from the DM?<br></blockquote><div><br></div><div>I am doing this, but it does not have to be the only way things work. What I do not understand is how this change breaks your stuff.</div><div>If you were setting the DMKSP compute callback, it should just override what I am doing above. If not, why does me setting it here</div><div>screw it up?</div><div><br></div><div>  Thanks,</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
<br>
Lawrence</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="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></div>