[petsc-dev] Attaching DMKSP/SNES/TS with PetscObjectCompose() change
Barry Smith
bsmith at mcs.anl.gov
Fri Nov 30 12:48:24 CST 2012
On Nov 30, 2012, at 11:53 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> We could make a fast key-based generic compose.
Why add all this complication when simply having the placeholders (which we KNOW we need) is fast and simple. Again this is more philosophical
Barry
>
> On Nov 30, 2012 11:36 AM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
>
> On Nov 30, 2012, at 11:30 AM, Matthew Knepley <knepley at gmail.com> wrote:
>
> >
> > On Nov 30, 2012 11:17 AM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > >
> > >
> > > I would like to add to the _p_DM struct
> > >
> > > PetscObject dmksp, dmsnes, dmts.
> > >
> > > The current model that uses PetscObjectCompose() is a mis-use of PetscObjectCompose(), why?
> > >
> > > The PetscObjectQuery() is always used for every function evaluation in every time step, every Newton step, …
> > >
> > > 1) this is a performance problem with small size ODEs for example
> > >
> > > 2) PetscObjectQuery is suppose to be for exceptional things that occur seldomly, not ones that occur inside the main computational routes.
> > >
> > >
> > >
> > > Please send any technical (not philosophical) reasons why making this change is a bad idea and will haunt us later.
> >
> > There is an extensibility problem that Jed has already noted.
>
> That is only a philosophical objection :-) If one wishes to add a DMGetDMTAOSomething() they can implement it with the PetscObjectCompose() model so things are still extensible.
>
>
>
> Barry
>
> >
> > Matt
> >
> > > Barry
> > >
> > >
> > >
> > >
> >
>
More information about the petsc-dev
mailing list