[petsc-dev] One DM two SNES

Jed Brown jed at jedbrown.org
Wed Nov 1 19:46:51 CDT 2017


Matthew Knepley <knepley at gmail.com> writes:

> On Wed, Nov 1, 2017 at 6:50 PM, Blaise A Bourdin <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


More information about the petsc-dev mailing list