[petsc-dev] Promote MatShellSetOperation() and MatShellSetContext() to Mat

[Barry Smith]

   I am not yet comfortable with a MatSetApplicationContext() nor a VecSetApplicationContext(). I do think it makes sense to have a PCSetApplicationContext().

  Should the "solver" application contexts be unified in the following way. 

     TSSetApplicationContext() calls SNESSetApplicationContext() calls KSPSetApplicationContext() calls PCSetApplicationContext(). And users with nonlinear problems call SNESSetApplicationContext() directly and linear problems call KSPSetApplicationContext() directly, of course.

    Meanwhile DMSetContext() is changed to DMSetApplicationContext(), while MatShellSetContext() remains MatShellSetContext().  Note that it does not have application in it because it is the MatShell context only. 


    Barry


On Jun 6, 2011, at 6:25 AM, Jed Brown wrote:

> We already semi-sanction using MatShellSetOperation() to provide different implementations for matrices that are not of type MATSHELL. An example of this is having a matrix-free way to apply the action of a MatNest in one pass over the mesh.
> 
> The problem is that one can't call MatShellGetContext() if given a matrix of a type that is not MATSHELL. MatShellSetContext() is just silently ignored and then NULL is returned by MatShellGetContext().
> 
> Should we promote these functions to Mat, as in MatSetOperation(), MatSetContext(), and MatGetContext()?
> 
> The alternative is for the user to make their application context a PetscObject so that it can be composed. I've done this quite a lot, but I don't think it should be necessary.
> 
> Also, this looks like a minor naming inconsistency:
> 
> PCShellSetContext
> DMSetContext
> MatShellSetContext
> 
> KSPSetApplicationContext
> SNESSetApplicationContext
> TSSetApplicationContext