[petsc-dev] who broke petsc-dev

[Barry Smith]

On Nov 13, 2011, at 5:22 PM, Matthew Knepley wrote:

> On Sun, Nov 13, 2011 at 11:13 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> On Nov 13, 2011, at 5:05 PM, Matthew Knepley wrote:
> 
> > On Sun, Nov 13, 2011 at 10:52 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >   The simplest fix is to only do this null space business if Amat exists.
> >
> > I did this.
> >
> >   But keep in mind that KSP and SNES now have two modes of operation, the second uses the DM to provide many of the items they need at setup time. This is different then the classic KSP and SNES where the only way to do things were with KSPSetOperators() and SNESSetFunction/Jacobian. This is why Jed is indicating that it may be too soon at this stage to muck with the null space business.
> >
> > This is bad. Things are becoming unacceptably complicated. I can't trust that obvious arguments are in this function,
> > and I can't trust that setup will be called since the logic is convoluted. This needs to be rethought.
> 
>  Do you want to go back to the uncomposible DMMG?    The logic is not all that convoluted. Basically at setup time for any thing that has not be previously provided KSP and SNES try to use DM to provide them.
> 
> No. The setup logic for KSP is convoluted.

   Any simplification that still supports all the use cases would be greatly appreciated. I would like it to be simplier but do not know how.
>  
>  The alternative is to remove KSPSetOperators() and SNESSetFunction/Jacobian() and ONLY have them provided with DM.  I dislike this because it breaks our 15 year old model and all users (even the least skilled) need to deal with yet another object before they can solve the simplest thing. But I am open to other alternative designs that you might suggest.
> 
> I do not want that. I would rather that people using DM do not call KSPSetOperators() at all. The only reason that we would call it
> is to pass the preconditioner. I think this overloading of the interface complicates things. I would prefer adding a call for the
> preconditioning matrix, that gets called from KSPSetOeprators() and can be called if you are using DM.

  So you would rather have a KSPSetOperatiors() and KSPSetPreconditionerOperator() both rather than just support KSPSetOperators() taking a PETSC_NULL for some of the arguments? That is certainly not the standard way we do things in PETSc. We generally support all kinds of subsets of passing arguments and nulls in various places and I don't see a problem with it here.

  Normally people using DM DO NOT CALL KSPSetOperators(),  (but they can).

  Barry


> 
>    Matt
>  
> 
>   Barry
> 
> >
> >    Matt
> >
> >
> >   Barry
> >
> >
> > On Nov 13, 2011, at 4:47 PM, Matthew Knepley wrote:
> >
> > > On Sun, Nov 13, 2011 at 10:47 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > >
> > > On Nov 13, 2011, at 4:45 PM, Matthew Knepley wrote:
> > >
> > > > On Sun, Nov 13, 2011 at 10:44 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > > > On Sun, Nov 13, 2011 at 16:36, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > > 1) It is legitimate to call KSPSetOperators with a null Amat so this is a bug that crashes large parts of PETSc
> > > >
> > > > This logic should be moved much later (like to KSPSetUp()).
> > > >
> > > > I disagree, since SetOperators() is where we know that the matrix is changing.
> > >
> > >  Yes, but the matrix may not exist.
> > >
> > > I have no problem fixing this, but what does that mean? I can't fix it until I understand what you are doing here.
> > >
> > >   Matt
> > >
> > > >
> > > >    Matt
> > > >
> > > >
> > > >
> > > > 2) Do you really want to do this? I am not sure I like it.
> > > >
> > > > I think that attaching the null space to the Mat should be the preferred way to communicate it, especially in the case of a deeply nested hierarchy.
> > > >
> > > >
> > > >
> > > > --
> > > > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> > > > -- Norbert Wiener
> > >
> > >
> > >
> > >
> > > --
> > > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> > > -- Norbert Wiener
> >
> >
> >
> >
> > --
> > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> > -- Norbert Wiener
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener