[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