[petsc-users] block matrix without MatCreateNest

[Klaij, Christiaan]

OK, looking forward to the fix!

Related to this, the preallocation would need to depend on the
type that is given at runtime, say

if type=XXX, call MatXXXSetPreallocation()

That would work for say seqaij and mpiaij, probably even without
the if-statement, right? And since there's no
MatNestSetPreallocation, should one get the submats and
preallocate those if type=nest?

Chris

> Date: Tue, 2 Aug 2016 08:49:36 -0500
> From: Matthew Knepley <knepley at gmail.com>
> To: "Klaij, Christiaan" <C.Klaij at marin.nl>
> Cc: "petsc-users at mcs.anl.gov" <petsc-users at mcs.anl.gov>
> Subject: Re: [petsc-users] block matrix without MatCreateNest
> Message-ID:
>         <CAMYG4Gk9-cp8nrHnkCePnUvty-emDWSMQco0S3AJ5u8_W=fiXw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Aug 2, 2016 at 2:25 AM, Klaij, Christiaan <C.Klaij at marin.nl> wrote:
>
> > Thanks for your help! Going from individual blocks to a whole
> > matrix makes perfect sense if the blocks are readily available or
> > needed as fully functional matrices. Don't change that! Maybe add
> > the opposite?
> >
> > I'm surprised it's broken though: on this mailing list several
> > petsc developers have stated on several occasions (and not just
> > to me) things like "you should never have a matnest", "you should
> > have a mat then change the type at runtime", "snes ex70 is not
> > the intended use" and so on.
> >
> > I fully appreciate the benefit of having a format-independent
> > assembly and switching mat type from aij to nest depending on the
> > preconditioner. And given the manual and the statements on this
> > list, I thought this would be standard practice and therefore
> > thoroughly tested. But now I get the impression it has never
> > worked...
> >
> Yes, that way has never worked. Nest is only a memory optimization, and with
> implicit problems I am never running at the limit of memory (or I use more
> procs).
> The people I know who needed it had explicitly coded it in rather than
> trying to
> use it from options. It should not take long to get this fixed.
>
>   Thanks,
>
>      Matt
>
> > Chris
> >
> >
> > > From: Matthew Knepley <knepley at gmail.com>
> > > Sent: Tuesday, August 02, 2016 12:28 AM
> > > To: Klaij, Christiaan
> > > Cc: petsc-users at mcs.anl.gov; Jed Brown
> > > Subject: Re: [petsc-users] block matrix without MatCreateNest
> > >
> > > On Mon, Aug 1, 2016 at 9:36 AM, Klaij, Christiaan <C.Klaij at marin.nl>
> > wrote:
> > >
> > >     Matt,
> > >
> > >
> > >     1) great!
> > >
> > >
> > >     2) ??? that's precisely why I paste the output of "cat mattry.F90"
> > in the emails, so you have a small example that produces the errors I
> > mention. Now I'm also attaching it to this email.
> > >
> > > Okay, I have gone through it. You are correct that it is completely
> > broken.
> > >
> > > The way that MatNest currently works is that it trys to use L2G mappings
> > from individual blocks
> > > and then builds a composite L2G map for the whole matrix. This is
> > obviously incompatible with
> > > the primary use case, and should be changed to break up the full L2G
> > into one for each block.
> > >
> > > Jed, can you fix this? I am not sure I know enough about how Nest works.
> > >
> > >    Matt
> > >
> > >     Thanks,
> > >
> > >     Chris


dr. ir. Christiaan Klaij  | CFD Researcher | Research & Development
MARIN | T +31 317 49 33 44 | mailto:C.Klaij at marin.nl | http://www.marin.nl

MARIN news: http://www.marin.nl/web/News/News-items/Vice-Admiral-De-Waard-makes-virtual-test-voyage-on-MARINs-FSSS.htm