[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