<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 25, 2012 at 4:41 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On Apr 25, 2012, at 4:33 PM, Dmitry Karpeev wrote:<br>
<br>
><br>
><br>
> On Wed, Apr 25, 2012 at 4:09 PM, Mark F. Adams <<a href="mailto:mark.adams@columbia.edu">mark.adams@columbia.edu</a>> wrote:<br>
><br>
> On Apr 25, 2012, at 3:48 PM, Barry Smith wrote:<br>
><br>
</div><div class="im">> > or is it a more vague thing that defined by "well if you compute Pt A P the result has a blocksize of nbs".  In that case we would provide a MatSetVirtualColumnBlockSize()<br>
> ><br>
><br>
> All I really need is for the coarse grid matrix to have the block size, because that is used to create a graph (for "vertices" not equations).  The method that constructs the prolongator knows the block size, so I attach it to P.  I could actually attach the block size to the coarse matrix in the way that I do with P, or pass it around as a parameter internally, I suppose.<br>


><br>
> Actually, in my opinion, this is the cleanest solution: attach the column block size to P and then to Ac = PtAP.<br>
> All of this currently happens inside GAMG, which has access to the composed datum's id.<br>
> Otherwise we are expanding the API with MatSetVirtualColumnSize(), which basically has no meaning outside GAMG.<br>
> I think the data composition mechanism exists exactly for these specific cases.<br>
><br>
> Dmitry.<br>
<br>
</div>    Dmitry,<br>
<br>
      The problem with that approach is that the routine that forms PtAP is a generic routine, (nothing to do with GAMG) and so it cannot be getting GAMG specific composed datuums out of the P.<br>
<br>
      I do not want the block size passed as an argument to PtAP() because that is a real ugly interface and the block size information arises from the matrix P and A, not from some arbitrary value one could pass into PtAp().<br>

</blockquote><div><br></div><div>I totally agree with all of this.  I think the *caller* of PtAP() (in this case a PCGAMG method ), should extract the </div><div>column block size from P and attach it to Ac = PtAP.  (Actually, from what I understand, it's available in PC_GAMG itself after PCSetCoordinates(), but Mark will correct me, if I'm wrong).  It will sit there until Ac's turn to be coarsened, etc. Only GAMG currently knows (and cares) about the meaning of this block size, and it's also uniquely positioned to attach and extract this information at will.</div>

<div><br></div><div>Dmitry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
    Barry<br>
<br>
  I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> Mark<br>
><br>
> >    Thanks<br>
> ><br>
> >   Barry<br>
> ><br>
> >><br>
> >> Mark<br>
> >><br>
> >>> Hong<br>
> >>><br>
> >>> And MatGetSubMatrix has to inherit block size, which I assume is trial.<br>
> >>><br>
> >>> Mark<br>
> >>><br>
> >>> On Apr 24, 2012, at 11:14 PM, Barry Smith wrote:<br>
> >>><br>
> >>>><br>
> >>>> On Apr 24, 2012, at 8:14 PM, Mark F. Adams wrote:<br>
> >>>><br>
> >>>>><br>
> >>>>> On Apr 24, 2012, at 5:01 PM, Barry Smith wrote:<br>
> >>>>><br>
> >>>>>><br>
> >>>>>> On Apr 24, 2012, at 2:38 PM, Mark F. Adams wrote:<br>
> >>>>>><br>
> >>>>>>><br>
> >>>>>>> On Apr 24, 2012, at 3:28 PM, Hong Zhang wrote:<br>
> >>>>>>><br>
> >>>>>>>> Mark :<br>
> >>>>>>>> Shall C=PtAP inherit the block size of A?<br>
> >>>>>>>> Currently, MatPtAP() is only implemented with aij bs=1.<br>
> >>>>>>><br>
> >>>>>>> No, as I said, algebraically it should inherit the column block size of P, but that is not available.<br>
> >>>>>><br>
> >>>>>> What is the column block size of P and how do you know what it is?<br>
> >>>>><br>
> >>>>> I now attach it to the P matrix instead of adding it as a return parameter of the create P method.  So I keep track of it in the code.  Its size is the number of null space vectors.<br>
> >>>><br>
> >>>> Ok if P knows its block size then the code that computes PtAP can set the block size of the resulting matrix as it creates it using the information in P. So is the issue on calling MatSetBlockSize() now resolved and everyone happy?<br>


> >>>><br>
> >>>>  Barry<br>
> >>>><br>
> >>>>><br>
> >>>>> Mark<br>
> >>>>><br>
> >>>>>><br>
> >>>>>> Barry<br>
> >>>>>><br>
> >>>>>>><br>
> >>>>>>> Perhaps PtAP should take a parameter for the block size ...<br>
> >>>>>>><br>
> >>>>>>> Mark<br>
> >>>>>>><br>
> >>>>>>>> Hong<br>
> >>>>>>>><br>
> >>>>>>>> On Apr 24, 2012, at 2:55 PM, Barry Smith wrote:<br>
> >>>>>>>><br>
> >>>>>>>>><br>
> >>>>>>>>> On Apr 24, 2012, at 1:39 PM, Mark F. Adams wrote:<br>
> >>>>>>>>><br>
> >>>>>>>>>> Now I'm getting this error with code like this:<br>
> >>>>>>>>>><br>
> >>>>>>>>>> ierr = MatGetSubMatrix( Cmat, new_eq_indices, new_eq_indices, MAT_INITIAL_MATRIX, &mat );<br>
> >>>>>>>>>> CHKERRQ(ierr);<br>
> >>>>>>>>>> ierr = MatSetBlockSize( mat, cbs );      CHKERRQ(ierr);<br>
> >>>>>>>>>><br>
> >>>>>>>>>> and like this:<br>
> >>>>>>>>>><br>
> >>>>>>>>>> ierr = MatPtAP( Amat_fine, Pold, MAT_INITIAL_MATRIX, 2.0, &Cmat ); CHKERRQ(ierr);<br>
> >>>>>>>>>> ierr = MatSetBlockSize( Cmat, cbs );      CHKERRQ(ierr);<br>
> >>>>>>>>><br>
> >>>>>>>>> Right you cannot do this. The matrix already exists so you cannot now set its size.<br>
> >>>>>>>>><br>
> >>>>>>>>> Does Cmat have a block size of cbs<br>
> >>>>>>>>><br>
> >>>>>>>>> What about Amat?   By default these routines should create the new matrix with the correct blocksize.<br>
> >>>>>>>>><br>
> >>>>>>>>> The harder part is if the blocksize of mat would be different than Cmat?<br>
> >>>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>> It seems like MatGetSubMatrix should just inherit the block size but PtAP is harder.  The block size of the Cmat is the column block size of P.  But I can not set a column block size (!= row block size) so I don't set block size on P at all.  Here cbs is this column block size of P, or what it should be.<br>


> >>>>>>>><br>
> >>>>>>>> Mark<br>
> >>>>>>>><br>
> >>>>>>>>> Barry<br>
> >>>>>>>>><br>
> >>>>>>>>>><br>
> >>>>>>>>>> Mark<br>
> >>>>>>>>>><br>
> >>>>>>>>>> On Apr 23, 2012, at 9:09 PM, Barry Smith wrote:<br>
> >>>>>>>>>><br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Yes, look, for example how ex32 is handled at the bottom of the makefile.<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Thanks<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Barry<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> On Apr 23, 2012, at 5:50 PM, Mark F. Adams wrote:<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>>><br>
> >>>>>>>>>>>> On Apr 23, 2012, at 5:59 PM, Barry Smith wrote:<br>
> >>>>>>>>>>>><br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>>> It was changed a while ago that MatSetBlockSize() couldn't be set after the matrix was full instantiated. I guess that example did not get fixed because it is not listed in the makefile to run in the makeall.<br>


> >>>>>>>>>>>><br>
> >>>>>>>>>>>> May I add it?<br>
> >>>>>>>>>>>><br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>>> I have fixed the example to call MatSetBlockSize() at a safe point.<br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>>> Barry<br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>>> On Apr 23, 2012, at 4:29 PM, Mark F. Adams wrote:<br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>>>> ex55.c in ksp is failing with:<br>
> >>>>>>>>>>>>>><br>
> >>>>>>>>>>>>>> [0]PETSC ERROR: --------------------- Error Message ------------------------------------<br>
> >>>>>>>>>>>>>> [0]PETSC ERROR: Arguments are incompatible!<br>
> >>>>>>>>>>>>>> [0]PETSC ERROR: Cannot change block size 1 to 2!<br>
> >>>>>>>>>>>>>> [0]PETSC ERROR: ------------------------------------------------------------------------<br>
> >>>>>>>>>>>>>><br>
> >>>>>>>>>>>>>> on this line 57 of ex55.c:<br>
> >>>>>>>>>>>>>><br>
> >>>>>>>>>>>>>> ierr = MatSetBlockSize(Amat,2);      CHKERRQ(ierr);<br>
> >>>>>>>>>>>>>><br>
> >>>>>>>>>>>>>> Any idea what happened here?<br>
> >>>>>>>>>>>>>><br>
> >>>>>>>>>>>>>> Mark<br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>>><br>
> >>>>>>>>>>>><br>
> >>>>>>>>>>><br>
> >>>>>>>>>>><br>
> >>>>>>>>>><br>
> >>>>>>>>><br>
> >>>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>><br>
> >>><br>
> >><br>
> ><br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>