[petsc-dev] questions regarding TSDM

[Peter Brune]

This was an unfortunate case of the peril of providing legacy support.
We're transitioning away from them.  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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121120/4747e2cc/attachment.html>