[petsc-dev] use of deprecated DMSetFunction() approach

[Jed Brown]

On Sun, Nov 25, 2012 at 5:20 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>    Matt,
>
>      The use of DMSetFunction/Jacobian was deprecated many months ago when
> KSPDM, SNESDM, and TSDM were introduced but you seem to be merrily using it
> to build a complete DMSetLocalFunction() infrastructure?   I already gave
> Jed and Peter a serious tongue lashing for "providing backward compatible
> support for DMSetFunction()" and not completely stripping it out when they
> wrote the replacement, as the PETSc style guide requires they should have
> done.
>
>
>    Everyone,
>
>    But now what are we going to do? We need to support
>
> 1) the usual "global" SNES/TS/KSP Set Function/Jacobian
>
> 2) special DM specific function/Jacobian evaluations such as
>
>      a)  finite elment style SNES/TS/KSP Set Local (ghosted)
> Function/Jacobin
>
>       b) DA oriented set local function/Jacobian
>
>
> The KSPDM/SNESDM/TSDM model seems ok for managing 1)  but how do we plan
> to manage all the 2)?


DMDASNESSetFunctionLocal() and similar. To use those routines, you must
"know about DM", thus there is no hardship in setting your callbacks on the
DM.

Note that SNESSetFunction() trivially redirects into DMSNESSetFunction() so
it is doing nothing more than hiding DM from users that are not interested
in using it.


> The comments in the code
>
>   /* This context/destroy pair allows implementation-specific routines
> such as DMDA local functions. */
>   PetscErrorCode (*destroy)(KSPDM);
>   void *data;
>

A duplicate routine should be here, but nobody has written
DMDAKSPSetComputeOperators() so it wasn't being used.

https://bitbucket.org/petsc/petsc-dev/changeset/026daea85c5c24fc64f04357af2f13afc6b23697


>
>   /* This context/destroy pair allows implementation-specific routines
> such as DMDA local functions. */
>   PetscErrorCode (*destroy)(SNESDM);
>   PetscErrorCode (*duplicate)(SNESDM,DM);
>   void *data;
>
>   /* This context/destroy pair allows implementation-specific routines
> such as DMDA local functions. */
>   PetscErrorCode (*destroy)(TSDM);
>   void *data;
>

Duplicate was needed here.

https://bitbucket.org/petsc/petsc-dev/changeset/d5619197e506fdb0622ba24b0e3c26ddbee596aa


>
> seem to indicate someone has thought about his but how the f it is planned
> to be done is unclear (and why SNES requires a duplicate but KSP and TS do
> not?).  In particular what is the user interface would it be
>
> SNESDMDASetLocalFunction/Jacobian()?  or
> DMDASNESSetLocalFunction/Jacobian()?
>

DMDASNESSetFunctionLocal(), it has been there since March.


>
> I am also bothered by the more fundamental question of what is the
> expected user interface when there exists both
>
> SNESSetFunction()   and DMSNESSetFunction()?
>
> Are users suppose to either of them or just SNESSetFunction()? If just
> SNESSetFunction() then why is the level of DMSNESSetFunction() just
> advanced and not developer.   Having both of these is a major recipe for
> complete confusion for both users and developers.
>

My expectation is that 90% of users of DM will be able to use the
impl-specific local routines like DMDASNESSetFunctionLocal(). For the few
that need something more general (e.g., multiple communication phases in
residual evaluation), they could use either. DMSNESSetFunction() is
slightly more powerful than SNESSetFunction() because it can be set
independent of the SNES, but I think that is rarely important.

SNESSetFunction() is purely cosmetic, allowing people to use SNES without
needing to know about the DM concept. We can delete it if "more than one
way to do it" is worse that "yet another object to interact with", but I'm
doubtful.


>
> Also all the half-assed legacy support crap that has gotten in there makes
> the code incredibly fragile and is harder to get rid of then it should be.
>
> We need to pick a single consistent extensible model now and change
> everything to match that model, the current code makes us look like a bunch
> of Trilinos developers.
>
>    Barry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121125/96f22155/attachment.html>