[petsc-dev] block size information in gamg

[Stefano Zampini]

>
> 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.zampini at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161011/8c83db8e/attachment.html>