[petsc-dev] One DM two SNES

Jed Brown jed at jedbrown.org
Wed Nov 1 21:47:09 CDT 2017


Blaise A Bourdin <bourdin at lsu.edu> writes:

> On Nov 1, 2017, at 7:46 PM, Jed Brown <jed at jedbrown.org<mailto:jed at jedbrown.org>> wrote:
>
> Matthew Knepley <knepley at gmail.com<mailto:knepley at gmail.com>> writes:
>
> On Wed, Nov 1, 2017 at 6:50 PM, Blaise A Bourdin <bourdin at lsu.edu<mailto:bourdin at lsu.edu>> wrote:
>
> Hi,
>
> I have just spent 2h helping a student debugging a code, and I think that
> the problem is not ours…
> See the attached example: 1 create 1 DM and 2 SNES.
> If I assign the same DM to both SNES, the function and Jacobean of the
> second are ignored, and the first one is used.
> Replace the block l 138 - l. 149 with the one commented above, and the
> result is even weirder.
>
> Is this the intended behavior? If so, should there be a note of this
> behavior in the SNESSetDM man page?
>
> You can DMClone() when solving the other problem.
>
> I am not sure I understand everything this is doing, but I want to make an
> upfront point:
>
>  SNESSetFunction() is intended for use without a DM
>
> When the solver has a DM, we intend you to use
>
>  DMSNESSetFunctionLocal() and DMSNESSetJacobianLocal()
>
> This doesn't really matter -- SNESSetFunction just calls
> DMSNESSetFunction.  Getting rid of SNESSetFunction would save the
> confusion but break every existing PETSc code.
>
> However, now I think I see what is happening. The DMSNES is a structure
> that is intended to mediate between the solver
> and mesh. When you do SNESSetDM(), it copies over the DMSNES context. This
> context is already holding the formfunction
> and formjacobian pointers. Yes, this is confusing.
>
> Jed, how should this be documented?
>
> I don't know of a simple rule to prevent this in code.  You can have
> several SNES that are "related" in the sense that they help solve a
> given problem (nonlinear preconditioners, for example) and they can
> share a DM.  If you are solving different problems, you need to create a
> different DM.  Does this documentation help?
>
> https://bitbucket.org/petsc/petsc/commits/e03a659ce1e595e4412d70ada3603101a46e94e2
>
> Yes, I think it does. How about adding a  statement in the main DM man page stating that each field should get its SNES and its DM, possibly through cloning a main DM?

What is "each field"?  Normally we would recommend making one DM for all
the fields you are solving for, then solve it using one SNES (possibly
using some field-splitting decomposition).


More information about the petsc-dev mailing list