April 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] MetSetBlockSize issue
by Dmitry Karpeev 25 Apr '12

25 Apr '12

On Wed, Apr 25, 2012 at 5:58 PM, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > > On Apr 25, 2012, at 6:10 PM, Barry Smith wrote: > > > > > On Apr 25, 2012, at 4:58 PM, Jed Brown wrote: > > > >> On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to > hear alternatives. > >> > >> What about having a separate row and column block size? The BAIJ and > MAIJ formats can continue to store data using bs=gcd(rowbs,colbs), but > those row and column block sizes indicate that redundancy exists in the > data structure, so it can be utilized by appropriate operations. > > > > Mark told me in a earlier email that the "column block size" isn't > really the column block size (except in some cases), since it is not really > a column block size I don't want the matrix to list it as the column block > size (hence my virtual column block size thing). > > The blocks are not always dense, so by what appears to be your definition > of block size it is not (always) a 'column block size'. But I think that > it is semantically a blocked matrix and hence it has a column block size. > Yes, but with this one would always set mat values in blocks, and preallocation would have to be done in multiples of cbs. You could set some values to 0, of course. It looks like in building P (at least in AGG) you do just that -- set the values in column blocks of cbs. Dmitry. > > > > > If it is truly a column block size then great, P is given the column > block size with MatSetColumnBlockSize() or MatSetBlockSizes(mat,col,row) > and PtAP automatically uses that column block size for the resulting matrix > block size. > > > > I think this solution is the best (eg, no 'virtual'). Column block size > is a fundamental property of a blocked matrix. PETSc's current > implementations do not exploit or accommodate this but since it is a > fundamental property I do not mind cluttering up Mat with yet another > parameter. You deal with rectangular matrices, and blocked matrices, why > not rectangular blocks? You also have row block size on AIJ matrices that > do not have dense blocks so why not column block size? > > Mark > > > So Mark I ask you again, in GAMG is it truly a column block size? > > > > Barry > > > > > > > >

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Mark F. Adams 25 Apr '12

25 Apr '12

On Apr 25, 2012, at 6:10 PM, Barry Smith wrote: > > On Apr 25, 2012, at 4:58 PM, Jed Brown wrote: > >> On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives. >> >> What about having a separate row and column block size? The BAIJ and MAIJ formats can continue to store data using bs=gcd(rowbs,colbs), but those row and column block sizes indicate that redundancy exists in the data structure, so it can be utilized by appropriate operations. > > Mark told me in a earlier email that the "column block size" isn't really the column block size (except in some cases), since it is not really a column block size I don't want the matrix to list it as the column block size (hence my virtual column block size thing). The blocks are not always dense, so by what appears to be your definition of block size it is not (always) a 'column block size'. But I think that it is semantically a blocked matrix and hence it has a column block size. > > If it is truly a column block size then great, P is given the column block size with MatSetColumnBlockSize() or MatSetBlockSizes(mat,col,row) and PtAP automatically uses that column block size for the resulting matrix block size. > I think this solution is the best (eg, no 'virtual'). Column block size is a fundamental property of a blocked matrix. PETSc's current implementations do not exploit or accommodate this but since it is a fundamental property I do not mind cluttering up Mat with yet another parameter. You deal with rectangular matrices, and blocked matrices, why not rectangular blocks? You also have row block size on AIJ matrices that do not have dense blocks so why not column block size? Mark > So Mark I ask you again, in GAMG is it truly a column block size? > > Barry > > >

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Barry Smith 25 Apr '12

25 Apr '12

On Apr 25, 2012, at 4:58 PM, Jed Brown wrote: > On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives. > > What about having a separate row and column block size? The BAIJ and MAIJ formats can continue to store data using bs=gcd(rowbs,colbs), but those row and column block sizes indicate that redundancy exists in the data structure, so it can be utilized by appropriate operations. Mark told me in a earlier email that the "column block size" isn't really the column block size (except in some cases), since it is not really a column block size I don't want the matrix to list it as the column block size (hence my virtual column block size thing). If it is truly a column block size then great, P is given the column block size with MatSetColumnBlockSize() or MatSetBlockSizes(mat,col,row) and PtAP automatically uses that column block size for the resulting matrix block size. So Mark I ask you again, in GAMG is it truly a column block size? Barry

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Dmitry Karpeev 25 Apr '12

25 Apr '12

On Wed, Apr 25, 2012 at 4:58 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to >> hear alternatives. > > > What about having a separate row and column block size? The BAIJ and MAIJ > formats can continue to store data using bs=gcd(rowbs,colbs), but those row > and column block sizes indicate that redundancy exists in the data > structure, so it can be utilized by appropriate operations. > I agree. In fact, P's "column block size" (cbs) has exactly that meaning in the GAMG code (e.g., formProl0() in gamg/agg.c) -- it sets matrix values in adjacent multiples of cbs within each row. MatPtAP() could easily impart that block size (cbs = rbs, in this case) to its result. This way the meaning of "column block size" and "row block size" are meaningful for any matrix and not just within some particular context. Dmitry.

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Jed Brown 25 Apr '12

25 Apr '12

On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to > hear alternatives. What about having a separate row and column block size? The BAIJ and MAIJ formats can continue to store data using bs=gcd(rowbs,colbs), but those row and column block sizes indicate that redundancy exists in the data structure, so it can be utilized by appropriate operations.

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Mark F. Adams 25 Apr '12

25 Apr '12

On Apr 25, 2012, at 5:41 PM, Barry Smith wrote: > > On Apr 25, 2012, at 4:33 PM, Dmitry Karpeev wrote: > >> >> >> On Wed, Apr 25, 2012 at 4:09 PM, Mark F. Adams <mark.adams(a)columbia.edu> wrote: >> >> On Apr 25, 2012, at 3:48 PM, Barry Smith wrote: >> >>> 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() >>> >> >> 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. >> >> Actually, in my opinion, this is the cleanest solution: attach the column block size to P and then to Ac = PtAP. >> All of this currently happens inside GAMG, which has access to the composed datum's id. >> Otherwise we are expanding the API with MatSetVirtualColumnSize(), which basically has no meaning outside GAMG. >> I think the data composition mechanism exists exactly for these specific cases. >> >> Dmitry. > > Dmitry, > > 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. > > 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(). > Also, Dmitry, The coarse grid matrices do have this block data structure. So I can survive by doing it all in GAMG as I said but it is bad because then Mat methods, that can be faster with block size information, will not be able to exploit these optimizations. Mark > > Barry > > I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives. > > > >> >> Mark >> >>> Thanks >>> >>> Barry >>> >>>> >>>> Mark >>>> >>>>> Hong >>>>> >>>>> And MatGetSubMatrix has to inherit block size, which I assume is trial. >>>>> >>>>> Mark >>>>> >>>>> On Apr 24, 2012, at 11:14 PM, Barry Smith wrote: >>>>> >>>>>> >>>>>> On Apr 24, 2012, at 8:14 PM, Mark F. Adams wrote: >>>>>> >>>>>>> >>>>>>> On Apr 24, 2012, at 5:01 PM, Barry Smith wrote: >>>>>>> >>>>>>>> >>>>>>>> On Apr 24, 2012, at 2:38 PM, Mark F. Adams wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 24, 2012, at 3:28 PM, Hong Zhang wrote: >>>>>>>>> >>>>>>>>>> Mark : >>>>>>>>>> Shall C=PtAP inherit the block size of A? >>>>>>>>>> Currently, MatPtAP() is only implemented with aij bs=1. >>>>>>>>> >>>>>>>>> No, as I said, algebraically it should inherit the column block size of P, but that is not available. >>>>>>>> >>>>>>>> What is the column block size of P and how do you know what it is? >>>>>>> >>>>>>> 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. >>>>>> >>>>>> 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? >>>>>> >>>>>> Barry >>>>>> >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>>> >>>>>>>> Barry >>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps PtAP should take a parameter for the block size ... >>>>>>>>> >>>>>>>>> Mark >>>>>>>>> >>>>>>>>>> Hong >>>>>>>>>> >>>>>>>>>> On Apr 24, 2012, at 2:55 PM, Barry Smith wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Apr 24, 2012, at 1:39 PM, Mark F. Adams wrote: >>>>>>>>>>> >>>>>>>>>>>> Now I'm getting this error with code like this: >>>>>>>>>>>> >>>>>>>>>>>> ierr = MatGetSubMatrix( Cmat, new_eq_indices, new_eq_indices, MAT_INITIAL_MATRIX, &mat ); >>>>>>>>>>>> CHKERRQ(ierr); >>>>>>>>>>>> ierr = MatSetBlockSize( mat, cbs ); CHKERRQ(ierr); >>>>>>>>>>>> >>>>>>>>>>>> and like this: >>>>>>>>>>>> >>>>>>>>>>>> ierr = MatPtAP( Amat_fine, Pold, MAT_INITIAL_MATRIX, 2.0, &Cmat ); CHKERRQ(ierr); >>>>>>>>>>>> ierr = MatSetBlockSize( Cmat, cbs ); CHKERRQ(ierr); >>>>>>>>>>> >>>>>>>>>>> Right you cannot do this. The matrix already exists so you cannot now set its size. >>>>>>>>>>> >>>>>>>>>>> Does Cmat have a block size of cbs >>>>>>>>>>> >>>>>>>>>>> What about Amat? By default these routines should create the new matrix with the correct blocksize. >>>>>>>>>>> >>>>>>>>>>> The harder part is if the blocksize of mat would be different than Cmat? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> Mark >>>>>>>>>> >>>>>>>>>>> Barry >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Mark >>>>>>>>>>>> >>>>>>>>>>>> On Apr 23, 2012, at 9:09 PM, Barry Smith wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, look, for example how ex32 is handled at the bottom of the makefile. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Barry >>>>>>>>>>>>> >>>>>>>>>>>>> On Apr 23, 2012, at 5:50 PM, Mark F. Adams wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Apr 23, 2012, at 5:59 PM, Barry Smith wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> May I add it? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have fixed the example to call MatSetBlockSize() at a safe point. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Barry >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Apr 23, 2012, at 4:29 PM, Mark F. Adams wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ex55.c in ksp is failing with: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [0]PETSC ERROR: --------------------- Error Message ------------------------------------ >>>>>>>>>>>>>>>> [0]PETSC ERROR: Arguments are incompatible! >>>>>>>>>>>>>>>> [0]PETSC ERROR: Cannot change block size 1 to 2! >>>>>>>>>>>>>>>> [0]PETSC ERROR: ------------------------------------------------------------------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> on this line 57 of ex55.c: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ierr = MatSetBlockSize(Amat,2); CHKERRQ(ierr); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any idea what happened here? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Dmitry Karpeev 25 Apr '12

25 Apr '12

On Wed, Apr 25, 2012 at 4:41 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Apr 25, 2012, at 4:33 PM, Dmitry Karpeev wrote: > > > > > > > On Wed, Apr 25, 2012 at 4:09 PM, Mark F. Adams <mark.adams(a)columbia.edu> > wrote: > > > > On Apr 25, 2012, at 3:48 PM, Barry Smith wrote: > > > > > 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() > > > > > > > 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. > > > > Actually, in my opinion, this is the cleanest solution: attach the > column block size to P and then to Ac = PtAP. > > All of this currently happens inside GAMG, which has access to the > composed datum's id. > > Otherwise we are expanding the API with MatSetVirtualColumnSize(), which > basically has no meaning outside GAMG. > > I think the data composition mechanism exists exactly for these specific > cases. > > > > Dmitry. > > Dmitry, > > 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. > > 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(). > I totally agree with all of this. I think the *caller* of PtAP() (in this case a PCGAMG method ), should extract the 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. Dmitry. > > > Barry > > I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to > hear alternatives. > > > > > > > Mark > > > > > Thanks > > > > > > Barry > > > > > >> > > >> Mark > > >> > > >>> Hong > > >>> > > >>> And MatGetSubMatrix has to inherit block size, which I assume is > trial. > > >>> > > >>> Mark > > >>> > > >>> On Apr 24, 2012, at 11:14 PM, Barry Smith wrote: > > >>> > > >>>> > > >>>> On Apr 24, 2012, at 8:14 PM, Mark F. Adams wrote: > > >>>> > > >>>>> > > >>>>> On Apr 24, 2012, at 5:01 PM, Barry Smith wrote: > > >>>>> > > >>>>>> > > >>>>>> On Apr 24, 2012, at 2:38 PM, Mark F. Adams wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> On Apr 24, 2012, at 3:28 PM, Hong Zhang wrote: > > >>>>>>> > > >>>>>>>> Mark : > > >>>>>>>> Shall C=PtAP inherit the block size of A? > > >>>>>>>> Currently, MatPtAP() is only implemented with aij bs=1. > > >>>>>>> > > >>>>>>> No, as I said, algebraically it should inherit the column block > size of P, but that is not available. > > >>>>>> > > >>>>>> What is the column block size of P and how do you know what it is? > > >>>>> > > >>>>> 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. > > >>>> > > >>>> 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? > > >>>> > > >>>> Barry > > >>>> > > >>>>> > > >>>>> Mark > > >>>>> > > >>>>>> > > >>>>>> Barry > > >>>>>> > > >>>>>>> > > >>>>>>> Perhaps PtAP should take a parameter for the block size ... > > >>>>>>> > > >>>>>>> Mark > > >>>>>>> > > >>>>>>>> Hong > > >>>>>>>> > > >>>>>>>> On Apr 24, 2012, at 2:55 PM, Barry Smith wrote: > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Apr 24, 2012, at 1:39 PM, Mark F. Adams wrote: > > >>>>>>>>> > > >>>>>>>>>> Now I'm getting this error with code like this: > > >>>>>>>>>> > > >>>>>>>>>> ierr = MatGetSubMatrix( Cmat, new_eq_indices, new_eq_indices, > MAT_INITIAL_MATRIX, &mat ); > > >>>>>>>>>> CHKERRQ(ierr); > > >>>>>>>>>> ierr = MatSetBlockSize( mat, cbs ); CHKERRQ(ierr); > > >>>>>>>>>> > > >>>>>>>>>> and like this: > > >>>>>>>>>> > > >>>>>>>>>> ierr = MatPtAP( Amat_fine, Pold, MAT_INITIAL_MATRIX, 2.0, > &Cmat ); CHKERRQ(ierr); > > >>>>>>>>>> ierr = MatSetBlockSize( Cmat, cbs ); CHKERRQ(ierr); > > >>>>>>>>> > > >>>>>>>>> Right you cannot do this. The matrix already exists so you > cannot now set its size. > > >>>>>>>>> > > >>>>>>>>> Does Cmat have a block size of cbs > > >>>>>>>>> > > >>>>>>>>> What about Amat? By default these routines should create the > new matrix with the correct blocksize. > > >>>>>>>>> > > >>>>>>>>> The harder part is if the blocksize of mat would be different > than Cmat? > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> 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. > > >>>>>>>> > > >>>>>>>> Mark > > >>>>>>>> > > >>>>>>>>> Barry > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Mark > > >>>>>>>>>> > > >>>>>>>>>> On Apr 23, 2012, at 9:09 PM, Barry Smith wrote: > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Yes, look, for example how ex32 is handled at the bottom of > the makefile. > > >>>>>>>>>>> > > >>>>>>>>>>> Thanks > > >>>>>>>>>>> > > >>>>>>>>>>> Barry > > >>>>>>>>>>> > > >>>>>>>>>>> On Apr 23, 2012, at 5:50 PM, Mark F. Adams wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Apr 23, 2012, at 5:59 PM, Barry Smith wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> 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. > > >>>>>>>>>>>> > > >>>>>>>>>>>> May I add it? > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I have fixed the example to call MatSetBlockSize() at a > safe point. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Barry > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On Apr 23, 2012, at 4:29 PM, Mark F. Adams wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> ex55.c in ksp is failing with: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> [0]PETSC ERROR: --------------------- Error Message > ------------------------------------ > > >>>>>>>>>>>>>> [0]PETSC ERROR: Arguments are incompatible! > > >>>>>>>>>>>>>> [0]PETSC ERROR: Cannot change block size 1 to 2! > > >>>>>>>>>>>>>> [0]PETSC ERROR: > ------------------------------------------------------------------------ > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> on this line 57 of ex55.c: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> ierr = MatSetBlockSize(Amat,2); CHKERRQ(ierr); > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Any idea what happened here? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Mark > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >>> > > >> > > > > > > > > > > > >

1 0

Re: [petsc-dev] PETSc Bug Database, Issue Search
by Barry Smith 25 Apr '12

25 Apr '12

I would be perfectly happy to have a "bug database" for PETSc but I demand that it match our current workflow. I do not want to switch to some crappy webbased bug reporting system that both the developers and users hate. No one has yet demonstrated a "bug database" system that would match our current workflow.* I totally agree "that it is actually useful to users to be able to watch bugs or feature requests without the high volume of following petsc-dev or reading the Hg commit log to get news of action on it." this would be fantastic to have. Unfortunately the current tradeoff with proposed solutions is too high. Barry For example if you have some demon that tracks petsc-users, petsc-dev, and petsc-maint and collects the relevant information in a web database that would be utterly fantastic. On Apr 25, 2012, at 4:35 PM, Jed Brown wrote: > On Wed, Apr 25, 2012 at 16:27, Sou-Cheng (Terrya) Choi <sctchoi(a)uchicago.edu> wrote: > Hi Jed, > > May I ask where I could search for issues and maybe file bugs for the development version of PETSc? Are there any "bug database" where I could check the status, work-around, warnings/errors, etc? Thanks! > > Barry doesn't believe in having a place to keep track of this stuff because he thinks it causes bug reports to be closed prematurely or allows bugs to go too long without being fixed. So we discuss this stuff on petsc-dev or petsc-maint and it sits in our inboxes until someone fixes it. > > Every once in a while, Barry reiterates his contempt for bug trackers and I reiterate my perspective that it is actually useful to users to be able to watch bugs or feature requests without the high volume of following petsc-dev or reading the Hg commit log to get news of action on it. ;-) > > > There is this list of projects. > > http://www.mcs.anl.gov/petsc/developers/projects.html

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Barry Smith 25 Apr '12

25 Apr '12

On Apr 25, 2012, at 4:33 PM, Dmitry Karpeev wrote: > > > On Wed, Apr 25, 2012 at 4:09 PM, Mark F. Adams <mark.adams(a)columbia.edu> wrote: > > On Apr 25, 2012, at 3:48 PM, Barry Smith wrote: > > > 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() > > > > 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. > > Actually, in my opinion, this is the cleanest solution: attach the column block size to P and then to Ac = PtAP. > All of this currently happens inside GAMG, which has access to the composed datum's id. > Otherwise we are expanding the API with MatSetVirtualColumnSize(), which basically has no meaning outside GAMG. > I think the data composition mechanism exists exactly for these specific cases. > > Dmitry. Dmitry, 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. 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(). Barry I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives. > > Mark > > > Thanks > > > > Barry > > > >> > >> Mark > >> > >>> Hong > >>> > >>> And MatGetSubMatrix has to inherit block size, which I assume is trial. > >>> > >>> Mark > >>> > >>> On Apr 24, 2012, at 11:14 PM, Barry Smith wrote: > >>> > >>>> > >>>> On Apr 24, 2012, at 8:14 PM, Mark F. Adams wrote: > >>>> > >>>>> > >>>>> On Apr 24, 2012, at 5:01 PM, Barry Smith wrote: > >>>>> > >>>>>> > >>>>>> On Apr 24, 2012, at 2:38 PM, Mark F. Adams wrote: > >>>>>> > >>>>>>> > >>>>>>> On Apr 24, 2012, at 3:28 PM, Hong Zhang wrote: > >>>>>>> > >>>>>>>> Mark : > >>>>>>>> Shall C=PtAP inherit the block size of A? > >>>>>>>> Currently, MatPtAP() is only implemented with aij bs=1. > >>>>>>> > >>>>>>> No, as I said, algebraically it should inherit the column block size of P, but that is not available. > >>>>>> > >>>>>> What is the column block size of P and how do you know what it is? > >>>>> > >>>>> 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. > >>>> > >>>> 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? > >>>> > >>>> Barry > >>>> > >>>>> > >>>>> Mark > >>>>> > >>>>>> > >>>>>> Barry > >>>>>> > >>>>>>> > >>>>>>> Perhaps PtAP should take a parameter for the block size ... > >>>>>>> > >>>>>>> Mark > >>>>>>> > >>>>>>>> Hong > >>>>>>>> > >>>>>>>> On Apr 24, 2012, at 2:55 PM, Barry Smith wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> On Apr 24, 2012, at 1:39 PM, Mark F. Adams wrote: > >>>>>>>>> > >>>>>>>>>> Now I'm getting this error with code like this: > >>>>>>>>>> > >>>>>>>>>> ierr = MatGetSubMatrix( Cmat, new_eq_indices, new_eq_indices, MAT_INITIAL_MATRIX, &mat ); > >>>>>>>>>> CHKERRQ(ierr); > >>>>>>>>>> ierr = MatSetBlockSize( mat, cbs ); CHKERRQ(ierr); > >>>>>>>>>> > >>>>>>>>>> and like this: > >>>>>>>>>> > >>>>>>>>>> ierr = MatPtAP( Amat_fine, Pold, MAT_INITIAL_MATRIX, 2.0, &Cmat ); CHKERRQ(ierr); > >>>>>>>>>> ierr = MatSetBlockSize( Cmat, cbs ); CHKERRQ(ierr); > >>>>>>>>> > >>>>>>>>> Right you cannot do this. The matrix already exists so you cannot now set its size. > >>>>>>>>> > >>>>>>>>> Does Cmat have a block size of cbs > >>>>>>>>> > >>>>>>>>> What about Amat? By default these routines should create the new matrix with the correct blocksize. > >>>>>>>>> > >>>>>>>>> The harder part is if the blocksize of mat would be different than Cmat? > >>>>>>>>> > >>>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> Mark > >>>>>>>> > >>>>>>>>> Barry > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Mark > >>>>>>>>>> > >>>>>>>>>> On Apr 23, 2012, at 9:09 PM, Barry Smith wrote: > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Yes, look, for example how ex32 is handled at the bottom of the makefile. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> > >>>>>>>>>>> Barry > >>>>>>>>>>> > >>>>>>>>>>> On Apr 23, 2012, at 5:50 PM, Mark F. Adams wrote: > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Apr 23, 2012, at 5:59 PM, Barry Smith wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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. > >>>>>>>>>>>> > >>>>>>>>>>>> May I add it? > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have fixed the example to call MatSetBlockSize() at a safe point. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Barry > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Apr 23, 2012, at 4:29 PM, Mark F. Adams wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> ex55.c in ksp is failing with: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> [0]PETSC ERROR: --------------------- Error Message ------------------------------------ > >>>>>>>>>>>>>> [0]PETSC ERROR: Arguments are incompatible! > >>>>>>>>>>>>>> [0]PETSC ERROR: Cannot change block size 1 to 2! > >>>>>>>>>>>>>> [0]PETSC ERROR: ------------------------------------------------------------------------ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> on this line 57 of ex55.c: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> ierr = MatSetBlockSize(Amat,2); CHKERRQ(ierr); > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Any idea what happened here? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Mark > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > > > >

1 0

Re: [petsc-dev] PETSc Bug Database, Issue Search
by Sean Farley 25 Apr '12

25 Apr '12

> Barry doesn't believe in having a place to keep track of this stuff because > he thinks it causes bug reports to be closed prematurely or allows bugs to > go too long without being fixed. So we discuss this stuff on petsc-dev or > petsc-maint and it sits in our inboxes until someone fixes it. > > Every once in a while, Barry reiterates his contempt for bug trackers and I > reiterate my perspective that it is actually useful to users to be able to > watch bugs or feature requests without the high volume of following > petsc-dev or reading the Hg commit log to get news of action on it. ;-) I will, again, add +1 to having a searchable bug-tracker. Even if something is closed prematurely / ignored, then at least there is a place for this to be found. As opposed to having users sending duplicate emails about ignored issues. Case in point (even though Barry used the exact opposite reasoning), how would we have known that mpich2 is ignoring the issue that Jed found without it being publicly online? At least it saved us the time of finding out the hard way.

1 0