[petsc-dev] block size information in gamg

Stefano Zampini stefano.zampini at gmail.com
Tue Oct 11 07:54:29 CDT 2016


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.zampini at 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.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
>



-- 
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161011/5ead6561/attachment.html>


More information about the petsc-dev mailing list