[petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

[Hapla Vaclav]

> On 4 May 2019, at 20:49, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Smith, Barry F. via petsc-maint" <petsc-maint at mcs.anl.gov> writes:
> 
>>  Yes you have the history exactly right, butt keeping them as independent beasts seemed/seems impossible; except by doing something very cumbersome (like shoving all the PCXXX_YYY that depended on KSP into the KSP src directory). So the "opted" was really forced upon us.
> 
> We could merge PC and KSP into a single class, perhaps maintaining
> separate lists by typical "role" (the things we call PC are usually
> configured to be linear operations while the things we call KSP are
> iterative).  It would be a major change and I'm not suggesting we
> should, but it would eliminate a lot of duplication and associated
> controversy.

I remember you saying that already years ago and it sounds interesting. But I wonder how you would deal with the relative/absolute tolerance which is a crucial notion of KSP and has virtually no sense for PCs.

Although both these classes in a way "approximate the action of the inverse" as you said, iterative solvers can under some conditions reach the _a priori_ given tolerance, whereas preconditioners (without iteration on top of them, which would already mean combination of two solver types) just reach some tolerance which can be only evaluated _a posteriori_. In case of the ultimate ones lu/cholesky, it can be just slightly more than machine epsilon, but for others it can be virtually any number, often even greater than 1. It's then a question whether we could call it "approximating the inverse". That said the main goal of KSPs it to solve the linear problem with the given precision, whereas the main goal of PCs is "just" to reduce the condition number of the operator. And maybe combining them into a single class could bring more confusion rather than reduce it.

Vaclav