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

[Barry Smith]

On Aug 14, 2012, at 5:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Tue, Aug 14, 2012 at 4:19 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  Ok, but then that context cannot be used for any other purpose because of the possible conflict. Which means SNEScoloring thing must be changed.
> 
>    Why not use SNESSetApplicationContext() to get the ts into SNES?
> 
> I don't mind this, but I think it would be cleaner to change SNES coloring.
>  
> Here you are passing into the jacobian location something more general than the jacobian context.
> 
> Why is it more general? It's exactly the context needed to compute the Jacobian.
>  
> Do you also pass the ts to the SNESSetFunction() context?
> 
> Yes.
> 
> 
> I philosophically like having separate contexts for each callback because it avoids imposing a certain class structure on the user. That is, if we just had XXSetApplicationContext() and all the callbacks used that, it basically forces the user to implement each callback from the same class. I think that is usually the right design, but not always, and I'd hate to place that constraint on the user.

   Fine we can nuke SNESSetApplicationContext()

> 
> Now assuming that the flexibility above is good, we should not have SNES treat TS specially.

    Here you say SNES should not treat TS specially

> When someone wraps a different loop around SNES (optimization, UQ, etc), they should be able to compose using standard interfaces. This is why I think that SNES coloring is the misbehaving component.

   Here I do not understand. Why is TS allowed to use the SNESSetJacobian() context slot but SNES coloring is not allowed to?  What if someone wrote their own custom Compute Jacobian and wanted to use the context slot? To me that means TS is special it is the only one allowed to use that slot??  Here you are saying only TS is allowed to use the context slot.  WTF?

   Barry