Matthew Knepley <[email protected]> writes: > On Wed, Nov 1, 2017 at 6:50 PM, Blaise A Bourdin <[email protected]> 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
