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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>: >> >>> >>> >>> >>>> >>>> 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 < >>>> [email protected]> 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 >> > >
