[petsc-dev] block size information in gamg

[Mark Adams]

Note, I have a pull request in (for weeks) that adds a convergence study to
snes/ex56 so this might conflict Stefano is doing.

Also, next is broken because of what I think was an API change from Matt
et.al.  We are getting a bit tied up here.

On Fri, Oct 14, 2016 at 11:05 AM, Mark Adams <mfadams at lbl.gov> wrote:

> 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/934c61b1/attachment.html>