I'm glad that was easy to deal with. We need to clarify this.
Thanks, Mark On Tue, May 3, 2022 at 5:55 PM Randall Mackie <[email protected]> wrote: > > On May 3, 2022, at 12:37 PM, Mark Adams <[email protected]> wrote: > > >> Are you saying that now you have to explicitly set each 3x3 dense block, >> even if they are not used and that was not the case before? >> >> >> That was always the case before, you may have misinterpreted the meaning >> of a Mat block size? >> > > Actually block size is really more of a hint in that you don't have to set > 3x3 dense blocks and thus any AIJ matrix can have any block size > essentially. > At least that is my understanding. > There is a CI test that has sparse blocks and I ran into this issue with > GAMG optimizations. > (I had to add complicated code that Pierre actually found a bug in.) > > I don't know what changed in PETSc to make ASM fail for you, but if > MatConvert and ASM fail then PETSc is broken and always has been. > > I did not follow this whole thread, but Randall could you change your code > to add dense blocks or not use block size? > Sorry, but I just don't think we should support this (Pierre seems to > think that we do not) and we should "depreciate" this. > This needs to be discussed of course. > > Mark > > > Hi Mark and Pierre, > > You are correct that it is not necessary to use the block size. I had done > that many many years ago because for some reason I thought it was necessary > when creating a matrix for a 3D grid with more than 1 degree of freedom per > node. > > But as long as the matrix entries are set correctly, block size doesn’t > really matter. > > I think part of the issue in my situation is that there are parts of the > matrix where not all 3x3 dense blocks are set due to representing a > staggered grid system using a 3D DMDA (but like I say this was done many > years before DMStag was developed). > > > Thanks for the help and the clarifications, > > Randy > > > > >
