Here is a first attempt: stefano_zampini/allow-late-matsetblocksizes The new block sizes are not yet propagated to the diagonal and off-diagonal part. ex56 seems to produce the same AMG hierarchy.
2016-10-11 9:54 GMT+03:00 Stefano Zampini <stefano.zamp...@gmail.com>: > > > >> >> So it doesn't want to change the block size if map->range has been set >> (i.e. PetscLayoutSetUp()) was called. But if the matrix is AIJ so long as >> !(map->n % bs) one can actually set the block size at any time. So how >> about if I change the Mat code to allow setting the block size late for >> AIJ? Maybe we can also get rid of PCFieldSplitSetBlockSize() and a >> PCSPAISetBlockSize()? >> >> > This is precisely what I was referring to as hacking. For sure > MatSetBlockSize (and PetscLayoutSetBlockSize) can be patched if the bs > value passed in is valid (i.e. !(map->n % bs) == 1). > > >> One issue that comes up with this change is: should setting the block >> size later automatically reset the block size of the two inner AIJ >> matrices? Or should they remain one? I could have it update the inner block >> sizes at the expense of a tiny bit more code. But one complication is that >> MatSetUpMultiply_MPIAIJ() always sets the column block size of the >> off-diagaonl matrix to 1; so this needs to be respected. >> >> > I think the row block size of the inner matrices should be modified, as > well as the column block size of the diagonal part. > We should write a comprehensive test that sets the block sizes after > matrix setup to really understand what needs to be fixed. > I can take care of it if you wish. > > The PETSc design policy of "there is one way to do something" dictates >> that it is best not to have PCSetBlockSize() unless absolutely necessary so >> I am trying to see if it is absolutely necessary. >> >> > I was not asking for a general PCSetBlockSize(); just for a way to > customize GAMG when needed (something like HYPRE_BoomerAMGSetNumFunctions) > > > >> Barry >> >> >> >> >> > On Oct 10, 2016, at 10:18 AM, Stefano Zampini < >> stefano.zamp...@gmail.com> wrote: >> > >> > Mark, >> > >> > I was wondering if you could provide an API/command line customization >> for PCGAMG to explicitly provide the "block size" of the problem to the >> gamg solver, instead of using the block size of the matrix. The matrix >> block size could be always used as a fallback if this new information as >> not been provided. >> > >> > I'm interfacing a complicated finite element package to PETSc , where >> you cannot do any assumption on the blocksize of the problem during matrix >> setup, and (AFAIK) I cannot change the block size with a call to >> MatSetBlockSize after the matrix has been finalized without hacking (that I >> would like to avoid). >> > >> > Thanks >> > -- >> > Stefano >> >> > > > -- > Stefano > -- Stefano