<br><div class="gmail_quote">On Tue, Aug 14, 2012 at 5:16 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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"><div class="gmail_quote">On Tue, Aug 14, 2012 at 3:56 PM, Peter Brune <span dir="ltr"><<a href="mailto:prbrune@gmail.com" target="_blank">prbrune@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Correct; the sheer amount of code using this convention makes it exceedingly painful to fix.  It would be much easier to alter our internals.  I'm *this* close to fugueing on TS especially and removing all 
PetscObjects from ctx arguments internal to PETSc.  We can pass the TS around by PetscObjectCompose
 using the coarsen/restrict hooks.</blockquote></div><br></div><div>We could also punt with</div><div><br></div><div>void *PETSC_NULL_FORCE = &knownlocation;</div><div><br></div><div>I like the dogfooding of having TS pass itself as the context to SNES, but could be convinced to change my mind.</div>

</blockquote></div><br>I had to swear at it for a while and think of a way of getting it to work when I was doing the TS DMDA bindings, as you can't just set the TS as the context when you call DMDATSSetRHSJacobianLocal(DM, ... ) because you have no idea what the TS (or the appropriate SNES) is at that point.  I ended up having to set it in TSSetUp.<br>
<br>I'm still a bit torn on it, though.  I'm not sure that any other solution will end up looking better.<br><br>The MatFDColoring used in SNESComputeJacobianDefaultColor could be assumed to be attached to something.  This could either be the coloring off the DM, A coloring attached to the matrix itself, or something else.  It's not a big issue for us to remove the coloring argument, as long as the user has some ability to set a coloring in an appropriate spot.<br>
<br>- Peter<br><br>