On Tue, Nov 27, 2012 at 12:36 PM, Matthew Knepley <knepley at gmail.com> wrote: > On Tue, Nov 27, 2012 at 12:33 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >> On Nov 27, 2012, at 7:53 AM, Matthew Knepley <knepley at gmail.com> wrote: >> >>> On Tue, Nov 27, 2012 at 7:30 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: >>>> >>>> Matt, >>>> >>>> I have updated your dmcomplex examples to use >>>> DMSNESSetFunction/JacobianLocal() instead of DMSetLocalFunction/Jacobian() >>>> which I have removed. >>> >>> Did you run the tests? :) >> >> I ran 3 of the four examples using a test in builder.py they produced the >> same results before and after. The fourth example didn't compile (was >> out-dated) hence I did not run a test. > > Excellent. Builder is creeping into the usable range. Notice Jed's checkins.
I just ran the very first test for ex62 and get failure. Same for ex31. What are you running? Matt > Matt > >> Barry >> >>> >>> Matt >>> >>>> Barry >>>> >>>> On Nov 25, 2012, at 4:16 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote: >>>> >>>>> 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 >>>> >>> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which >>> their experiments lead. >>> -- Norbert Wiener >> > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
