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
