[petsc-dev] block size information in gamg

[Mark Adams]

FYI, I pushed a fix for snes/ex56 into knepley/feature-plex-bdfunc so this
should fix next.

On Fri, Oct 14, 2016 at 12:25 PM, Mark Adams <mfadams at lbl.gov> wrote:

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