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

[Barry Smith]

On Jun 6, 2011, at 3:25 PM, Jed Brown wrote:

> On Mon, Jun 6, 2011 at 22:05, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > The argument here is just that an inner object might not have a unique parent. In such cases, it would seem easier to manage if the first parent (or a direct call by the user) took precedence instead of the last parent.
> 
>  Hmm.  Weak argument?
> 
> Yeah, this might be an edge case in which a little extra user code is fine.
>  
>    I don't think there is a perfect solution to handling the nesting and I certainly don't think we have enough experience to come up with a great model to handle the nesting yet. We need to start down that road and see where it leads (look we don't even handle the nesting of DM well yet).
> 
> Note that if the user is actually using a DM, then they can use it to hold their application context. I think this is preferable. Setting the application context directly is (IMO) targeted at users who don't use DM at all.


    Since I very much like the software model of "there is only one way to do each thing" (the opposite of PERL and Mathematica) I've played around with the idea of ALWAYS having a DM. With a very simple default one when the user doesn't provide one. Maybe some day we'll be ready for that, but not yet.

   Barry


>  
>   You can use PetscContainerCreate() to keep the pointer to the struct.
> 
> 
> Ah, good point.
>  
>   Sounds like something special to MatNest()? Why not just have special MatNest code?
> 
> Yeah, that's reasonable. I anticipate the same issue with FETI-DP or anything else that naturally uses a hierarchical matrix format. The current solution is to always have an assembled non-hierarchical representation, but we have mostly focused on Dirichlet Schwarz methods. We can keep it all separate for now and consolidate if it becomes necessary. False sharing is worse than duplicating MatScale_X().