[petsc-dev] use of deprecated DMSetFunction() approach
Barry Smith
bsmith at mcs.anl.gov
Sat Nov 24 22:20:38 CST 2012
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
More information about the petsc-dev
mailing list