> On 4 May 2019, at 20:49, Jed Brown <[email protected]> wrote:
>
> "Smith, Barry F. via petsc-maint" <[email protected]> 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
