[petsc-dev] questions on new include organization

[Barry Smith]

On Feb 13, 2013, at 10:11 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Wed, Feb 13, 2013 at 10:02 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: 
>   Should we, should we not do the same thing for the other PCs? What about KSPs? Definitely no for KSPs.
> 
> PCFieldSplit would be the most likely candidate, but its interface is not that broad and it's not currently high-risk for growing dependencies, so I don't think there would be much return. I'm not the one that separated out petscpcmg.h and I'm not sure it's providing much value being separate. (It used to be called petscmg.h, I just renamed it to petscpcmg.h.)

   After trying to put it into petscpc.h I remembered why it was separate. It uses the KSP object. So either we put part of the interface in petscksp.h or typedef KSP in petscpc.h so I'll leave it as is for now.

   Barry

>  
> >
> >
> > **  Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right.
> >
> > I see the appeal of hierarchies, but I find them rigid and inconvenient. I definitely prefer object models (interface and implementation, but no implementation inheritance). The only reason for implementation inheritance is code sharing, but I think that's frequently a false economy and comes back to bite us in brittleness.
> 
>    The KSP -> gmres -> l or F; I am talking about is from the user perspective (I agree that any implementation inheritance is secondary and certainly not important to the users).  The question is do we give the user a list of 20 KSP or do we give them sets of related ones. I am arguing that presenting them as sets of related ones is better.
> 
> Arguably, GCR is more like FGMRES than FGMRES is like GMRES. LSQR is more like MINRES than MINRES is like GMRES, IDR is more like BCGSL than BCGSL is like BCGS, etc. I think this hierarchical classification does not work. Yahoo tried to do this with the internet and had their lunch eaten by Google.
> 
> We need searching, tagging, and perhaps semantic knowledge of properties, but I prefer a flat namespace to encoding the hierarchy induced by one choice of classification metric.