> > MatProductCreateWithMat(A,Vmat,NULL,Wmat); > MatProductSetType(Wmat,MATPRODUCT_AB); > MatHasOperation(Wmat,MATOP_MATPRODUCT,&flg); //new support, it calls > MatProductSetFromOptions(Wmat)
Hong, this would go in the direction I was outlining here https://gitlab.com/petsc/petsc/-/issues/608 <https://gitlab.com/petsc/petsc/-/issues/608> How about also adding something like MatProductIsImplemented(Wmat,&flg) That returns true if a specific implementation is available? This way This way, if we use both queries, we can assess the presence of the basic fallbacks too, i.e. MatHasOperation(Wmat,MATOP_MATPRODUCT,&flg1) MatProductIsImplemented(Wmat,&flg2) If flg1 is false, no support at all If flg1 is true and flg2 is false -> Basic implementation (i.e, MatShell with products inside) If flg1 and flg2 are both true -> Specific implementation available. > if (V->vmm && flg) { > MatProductSymbolic(Wmat); > MatProductNumeric(Wmat); > } else { > MatDestroy(Wmat); > ... > } > Hong > > > From: Jose E. Roman <jro...@dsic.upv.es> > Sent: Tuesday, April 21, 2020 11:21 AM > To: Pierre Jolivet <pierre.joli...@enseeiht.fr> > Cc: Zhang, Hong <hzh...@mcs.anl.gov>; petsc-dev <petsc-dev@mcs.anl.gov> > Subject: Re: [petsc-dev] MATOP_MAT_MULT > > > > > El 21 abr 2020, a las 17:53, Pierre Jolivet <pierre.joli...@enseeiht.fr> > > escribió: > > > > > > > >> On 21 Apr 2020, at 5:22 PM, Zhang, Hong <hzh...@mcs.anl.gov> wrote: > >> > >> Pierre, > >> MatMatMult_xxx() is removed from MatOps table. > > > > Shouldn’t there be a deprecation notice somewhere? > > There is nothing about MATOP_MAT_MULT in the 3.13 changelog > > https://www.mcs.anl.gov/petsc/documentation/changes/313.html > > <https://www.mcs.anl.gov/petsc/documentation/changes/313.html> > > For example, I see that in SLEPc, José is currently making these checks, > > which are in practice useless as they always return > > PETSC_FALSE?https://gitlab.com/slepc/slepc/-/blob/master/src/sys/classes/bv/impls/contiguous/contig.c#L191 > > > > <https://gitlab.com/slepc/slepc/-/blob/master/src/sys/classes/bv/impls/contiguous/contig.c#L191> > > (Maybe José is aware of this and this is just for testing) > > No, I was not aware of this. Thanks for bringing this up. Now in 3.13 we are > always doing the slow version (column by column), so yes I am interested in a > solution for this. > > > > >> MatMatMult() is replaced by > >> MatProductCreate() > >> MatProductSetType(,MATPRODUCT_AB) > >> MatProductSetFromOptions() > >> MatProductSymbolic() > >> MatProductNumeric() > >> > >> Where/when do you need query a single matrix for its product operation? > > > > I didn’t want to bother at first with the new API, because I’m only > > interested in C = A*B with C and B being dense. > > Of course, I can update my code, but if I understand Stefano’s issue > > correctly, and let’s say my A is of type SBAIJ, for which there is no > > MatMatMult, the code will now error out in the MatProduct? > > There is no fallback mechanism? Meaning I could in fact _not_ use the new > > API and will just have to loop on all columns of B, even for AIJ matrices. > > > > Thanks, > > Pierre > > > >> Hong > >> > >> From: petsc-dev <petsc-dev-boun...@mcs.anl.gov> on behalf of Pierre > >> Jolivet <pierre.joli...@enseeiht.fr> > >> Sent: Tuesday, April 21, 2020 7:50 AM > >> To: petsc-dev <petsc-dev@mcs.anl.gov> > >> Subject: [petsc-dev] MATOP_MAT_MULT > >> > >> Hello, > >> Am I seeing this correctly? > >> #include <petsc.h> > >> > >> int main(int argc,char **args) > >> { > >> Mat A; > >> PetscBool hasMatMult; > >> PetscErrorCode ierr; > >> > >> ierr = PetscInitialize(&argc,&args,NULL,NULL);if (ierr) return ierr; > >> ierr = MatCreate(PETSC_COMM_WORLD,&A);CHKERRQ(ierr); > >> ierr = MatSetType(A,MATMPIAIJ);CHKERRQ(ierr); > >> ierr = MatHasOperation(A,MATOP_MAT_MULT,&hasMatMult);CHKERRQ(ierr); > >> printf("%s\n", PetscBools[hasMatMult]); > >> ierr = PetscFinalize(); > >> return ierr; > >> } > >> > >> => FALSE > >> > >> I believe this is a regression (or at least an undocumented change) > >> introduced here: https://gitlab.com/petsc/petsc/-/merge_requests/2524/ > >> <https://gitlab.com/petsc/petsc/-/merge_requests/2524/> > >> I also believe Stefano raised a similar point there: > >> https://gitlab.com/petsc/petsc/-/issues/608 > >> <https://gitlab.com/petsc/petsc/-/issues/608> > >> This is a performance killer in my case because I was previously using > >> this check to know whether I could use MatMatMult or had to loop on all > >> columns and call MatMult on all of them. > >> There is also a bunch of (previously functioning but now) broken code, > >> e.g., > >> https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/transpose/transm.c.html#line105 > >> > >> <https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/transpose/transm.c.html#line105> > >> or > >> https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/nest/matnest.c.html#line2105 > >> > >> <https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/nest/matnest.c.html#line2105> > >> Is this being addressed/documented? > >> > >> Thanks, > >> Pierre > >
