[petsc-dev] block size information in gamg

[Mark Adams]

Stefano, There is a bug, I think, that was discussed on an earlier thread
and it did not get resolved AFAIK. If you feel like folding this into this
project (if you page it back in) then that would be nice. Here is a quote:

My pull request for snes/ex56 has:

ierr = VecNorm(xx,NORM_INFINITY,&mdisp[iter]);CHKERRQ(ierr);

When I tried to use VecStrideNorm I got the error that block size was not
set. You can't set it manually so I was stuck (not a big deal, but there is
either a bug in Plex or a bug in the way that I am using it).

Mark

On Tue, Oct 11, 2016 at 8:54 AM, Stefano Zampini <stefano.zampini at gmail.com>
wrote:

> 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_BoomerAMGSetNumFunc
>> tions)
>>
>>
>>
>>>   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/20161014/f74a7b12/attachment.html>