Simplify Reductors and Models

[sdrave]

This is non-functional code to give the @pymor/pymor-devs an idea of what I have in mind for the future Reductor design. It's probably more helpful to look at the new reductors/basic.py instead of looking at the diff. Comments welcome ..

As you can see, I have decided to completely remove the projection code from the base class. My impression was that there were too many corner cases to take care of and it might be clearer to explicitly write down the projections.

Fixes #587 when finished.

[renefritze]

Looks generally clearer to me.

[renefritze]

Is it intentional to leave check_orthonormality potentially unset below?
Should this be check_orthonormality = check_orthonormality or (basis in self.products)?

[sdrave]

There is a default for check_orthonormality in the free extend_basis function.

[sdrave]

BTW, regarding the use of inner products in project: To make things clearer, I could imagine to split project into a project_pg (or some other name) method which is project without the product argument and a project_orth(range_basis, source_basis, product=None, basis_is_orthonormal=False) method, which takes care of the orthogonal projection of an operator onto its image. project could then be deprecated and default implemented as project_orth(range_basis=range_basis, source_basis=source_basis, product=product, basis_is_orthonormal=True).

[pmli]

Looks ok to me. I guess the idea is to remove GenericePGReductor and add SecondOrderPGReductor etc., right?

I would prefer check_orthonormality to be False by default, since gram_schmidt is usually used before projection.

[sdrave]

So, the new Reductors should be working now (except for DelayBHIReductor and TFInterpReductor for which no tests seem to exist).

I have also removed operators from ModelInterface. This makes ModelBase quite simple. In particular, there are no longer any special_operators.

Documentation still needs updating.

@pmli, for now I have added an outputs dict to StationaryModel and InstationaryModel. From the PDE user's POV it seems natural to define several independent output functionals. We can discuss later on if this is desirable or not (to_lti could stack all functionals in a BlockOperator).

[pmli]

So, the new Reductors should be working now (except for DelayBHIReductor and TFInterpReductor for which no tests seem to exist).

Notebooks and demos appear to be working. TFInterpReductor (which should probably be renamed to TF_BHIReductor at some point) is kind of tested in heat.ipynb notebook and delay.py demo since it's used in TF-IRKA. DelayBHIReductor really is untested.

LTIPG and SOLTIPG reductors are a bit noisy, especially in IRKA, and especially when reporting "Assembling error estimator" which I'm pretty sure does nothing (or at least nothing relevant for BT and IRKA).

@pmli, for now I have added an outputs dict to StationaryModel and InstationaryModel. From the PDE user's POV it seems natural to define several independent output functionals. We can discuss later on if this is desirable or not (to_lti could stack all functionals in a BlockOperator).

Agreed.

[sdrave]

@pmli, ah sorry, TFInterpReductor should be working. DelayBHIReductor cannot work, since it is missing the right PGReductor attribute. Maybe you could fix that as an exercise on working with the new reductor approach 😄?

Regarding the logging: I have added a kind of ugly hack to prevent the estimator assembly log message from being displayed when there is no estimator to assemble. I would like to keep the other log messages in principle as they seem useful to me to see where time is spent. (I would not like to disable them for LTIPGReductor but keep them for the rb reductors as they are basically doing the same thing.) Right now, I am not completely satisfied with the way logging works. Basically I would like to have hierarchical log level s.t. nested log messages are suppressed if the parent messages are not displayed. This should be discussed in a separate issue, however.

[pmli]

I've added the DelayLTIPGReductor and a notebook which demonstrates DelayBHIReductor.

About logging, I agree about leaving "Operator projection" and "Building ROM" messages. My issue is that it pollutes the table in IRKAReductor, but maybe we can resolve it in another PR (e.g., by restructuring the table or silencing LTIPGReductor).

[sdrave]

@pmli, regarding logging: I think there is more important stuff right now than improving the logging, so I would go for 'e.g., by restructuring the table' ..