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