On Wed, Feb 13, 2013 at 10:02 PM, Barry Smith <[email protected]> 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.