[petsc-dev] questions on new include organization

[Jed Brown]

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.)


> >
> >
> > **  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130213/4df7c32f/attachment.html>