[petsc-dev] broken TS example related to Jacobian and coloring etc.

[Barry Smith]

On Aug 14, 2012, at 5:26 PM, Peter Brune <prbrune at gmail.com> wrote:

> 
> On Tue, Aug 14, 2012 at 5:16 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Tue, Aug 14, 2012 at 3:56 PM, Peter Brune <prbrune at gmail.com> wrote:
> 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.
> 
> We could also punt with
> 
> void *PETSC_NULL_FORCE = &knownlocation;
> 
> I like the dogfooding of having TS pass itself as the context to SNES, but could be convinced to change my mind.
> 
> 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.
> 
> I'm still a bit torn on it, though.  I'm not sure that any other solution will end up looking better.
> 
> 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.

    Yes it would "work" to remove the coloring context from that location to fix this one problem. But the bigger question is WHAT IS THAT LOCATION USED FOR? If the only thing that we can put into the last argument to SNESSetJacobian() or SNESSetFunction() is the TS then that is crazy and it should be removed from the user interface?  How about just having a SNESSetTS()? to take the ts (you could store it as a void*).

   We need a diagram of all the crazy shit we do now to juggle all these contexts and then we need to understand that diagram and improve it. It is too complicated and confusing now. Could you make a stab at making such a diagram (not how it should be, but how it is now)?

   Thanks



  
   Barry



> 
> - Peter
>