<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 10:21 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Nov 20, 2012, at 9:10 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> On Tue, Nov 20, 2012 at 3:08 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> The object is called TSDM but methods are DMTSXXX()?<br>
><br>
> 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<br>

><br>
><br>
> 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?<br>
><br>
> I don't mind making it a PetscObject.<br>
><br>
> 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?<br>

><br>
> 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.<br>

<br>
</div>   How do they "get out a coarse level and explicitly change it" for<br>
<br>
1) KSP?<br>
2) SNES?<br>
3) TS?<br>
<div class="im"><br>
><br>
><br>
> 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<br>
> 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).<br>

><br>
> Okay, but when the optimizers need to attach something, do we add special support for that in DM as well?<br>
<br>
</div>   Sure<br>
<div class="im"><br>
> 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.<br>
<br>
</div>  Ok, objectcompose is certainly more extensible.<br>
<br>
  BTW: DMTSGetContext() is kind of a funky name, context is a very general term, this function returns a TSDM  (or DMTS) so could be DMGetDMTS() or DMTSGetDMTS()<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Should it be DMGetTSDM?<br><br>I'v'e thought this (DMTS vs TSDM) an awkward distinction for a while too.  However, would removing weasel words like "Context" from the names make it more clear?<br>
<br>- Peter<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
>   Perhaps some refactoring could bring this stuff down to the simple-minded design of the rest of PETSc?<br>
><br>
>     Barry<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>