<p dir="ltr">We could make a fast key-based generic compose.</p>
<div class="gmail_quote">On Nov 30, 2012 11:36 AM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Nov 30, 2012, at 11:30 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
<br>
><br>
> On Nov 30, 2012 11:17 AM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> ><br>
> >    I would like to add to the _p_DM  struct<br>
> ><br>
> > PetscObject  dmksp, dmsnes, dmts.<br>
> ><br>
> >    The current model that uses PetscObjectCompose() is a mis-use of PetscObjectCompose(), why?<br>
> ><br>
> > The PetscObjectQuery() is always used for every function evaluation in every time step, every Newton step, …<br>
> ><br>
> > 1) this is a performance problem with small size ODEs for example<br>
> ><br>
> > 2) PetscObjectQuery is suppose to be for exceptional things that occur seldomly, not ones that occur inside the main computational routes.<br>
> ><br>
> ><br>
> ><br>
> >    Please send any technical (not philosophical) reasons why making this change is a bad idea and will haunt us later.<br>
><br>
> There is an extensibility problem that Jed has already noted.<br>
<br>
    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.<br>
<br>
<br>
<br>
    Barry<br>
<br>
><br>
>   Matt<br>
><br>
> >    Barry<br>
> ><br>
> ><br>
> ><br>
> ><br>
><br>
<br>
</blockquote></div>