On Nov 20, 2012, at 11:29 AM, Peter Brune <prbrune at gmail.com> wrote:
> This was an unfortunate case of the peril of providing legacy support. We're > transitioning away from them. Ok, I will hunt down all examples that use them and remove them. Then the harder problem becomes fixing the DMSetLocalFunction() since that also relies on this beast. Barry > In addition, we should move other things out of the DM, like > DMSet/ComputeVariableBounds(). > > - Peter > > > On Tue, Nov 20, 2012 at 11:24 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Are these things still used? Seems they should have been removed? > > petscdm.h:PETSC_EXTERN PetscErrorCode DMSetInitialGuess(DM,PetscErrorCode > (*)(DM,Vec)); > petscdm.h:PETSC_EXTERN PetscErrorCode DMSetFunction(DM,PetscErrorCode > (*)(DM,Vec,Vec)); > petscdm.h:PETSC_EXTERN PetscErrorCode DMSetJacobian(DM,PetscErrorCode > (*)(DM,Vec,Mat,Mat,MatStructure *)); > > > On Nov 20, 2012, at 9:10 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > On Tue, Nov 20, 2012 at 3:08 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > > The object is called TSDM but methods are DMTSXXX()? > > > > DMTS... is right because they are methods on a DM, though they are packaged > > with TS. The user _never_ sees the internal "TSDM" object. I think the > > original motivation for that naming structure was to prevent conflict with > > a TS/SNES implementation of the same name, but I would not object to > > switching to DMTS > > > > > > TSDM is itself not a PETSc object but it is wrapped into a PetscContainer > > (which is a PETSc object), so why not just make TSDM a PETSc object? Is it > > because of circular references? > > > > I don't mind making it a PetscObject. > > > > What's with the complicated DMTSGetContextWrite() (copy on write crapola) > > stuff? This kind of paradigm is not used anywhere else in PETSc, is it > > really needed? Seems overly complex, is it just to save a few small objects? > > > > It's for interface simplicity. If the user sets the the residual routine on > > the finest level and then changes it, they probably expect their change to > > propagate through the levels. But if they get out a coarse level and > > explicitly change it there, they probably intended to use a different > > discretization/physics on the coarse level. > > > > > > The DMTSGetContext() business uses PetscObjectCompose to attach the TSDM to > > a dm. Why not just have DM's have opaque pointers to KSPDM, SNESDM, and > > TSDM built into the DM and things > > like DMGetKSPDM() that do the usual dm->kspdm access instead of composing > > business. Since the business of DM's is to talk to TS, SNES, and KSP there > > is no reason to go through the more complicated object compose business is > > there? (The object compose business is for out-of-the-ordinary stashing of > > stuff, not ordinary stashing of stuff, it is kind of like using object > > compose to attach the ksp to the snes). > > > > Okay, but when the optimizers need to attach something, do we add special > > support for that in DM as well? What about UQ and so on? The idea here was > > to keep DM as ignorant as possible, but allow it to carry this extra data > > around for the various solver objects that need it. > > > > Perhaps some refactoring could bring this stuff down to the simple-minded > > design of the rest of PETSc? > > > > Barry > > > > > >
