> > 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 <[email protected]> > 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
