On Mar 15, 2011, at 6:03 PM, Matthew Knepley wrote:

> On Tue, Mar 15, 2011 at 6:00 PM, Jed Brown <jed at 59a2.org> wrote:
> On Tue, Mar 15, 2011 at 23:50, Matthew Knepley <knepley at gmail.com> wrote:
> That is not what I have here. I want to change a portion, but outside of that 
> I want it to fall back to a global matrix.
> 
> You were going to put your MatShell in the "pmat" slot, right? What are you 
> going to use for preconditioning the other blocks? If it's the same as in 
> "mat", you could use a MatNest for both operators and put the special sauce 
> in that slot of the "pmat".
> 
> This is the same objection Barry has. I do not want this tied to a particular 
> matrix impl for the global matrix.
   
  But you are tying it to a MATSHELL, that is a particular impl  

  Why not pass your Mat (maybe a global MPIAIJ) as the mat and pass your 
MatNest as your pmat and have some of the subblocks in the MatNest be defined 
by submatrices of of the MPIAIJ matrix. 

  That is, introduce a new matrix class that contains a pointer to a big matrix 
and two IS. The IS defines the part of the big matrix that this new matrix 
object represent. In this way you can build your pmat as a MatNest and put 
whatever stuff you want in some of its blocks but have the other blocks be 
defined as parts of the original mat (which is the big assed AIJ or anything 
else).


  Barry

>  
> If you assemble the matrix entirely monolithically (using MatSetValues 
> globally instead of MatSetValuesLocal on each physics separately), then we 
> haven't written MatSetValues_Nest yet so maybe your MatShell is the right 
> idea.
> 
> 
> Related: What do people think about having MatGetSubMatrix() retain ownership 
> of the submatrix?
> 
> Does it matter with our interface? Should be transparent.
> 
>    Matt
>  
> -- 
> What most experimenters take for granted before they begin their experiments 
> is infinitely more interesting than any results to which their experiments 
> lead.
> -- Norbert Wiener


Reply via email to