Parameterizing input-output models

[pmli]

Closes #487.

This is not yet ready to merge, so I'm testing the draft pull request feature.

I would like to hear comments from @pymor/pymor-devs about the changes concerning the usage of parameters, e.g. how often should parse_parameters be used and should matrix equation solvers expect a parameter or only work with non-parametric operators.

[renefritze]

I for one did not know about draft PRs until just now 👍

[sdrave]

@pmli, is there a concrete benefit to have the parameter in the matrix equation solver interface? If not, I would not see much reason to add a mu everywhere. For comparison, bindings.scipy.apply_inverse also does not support parameters.

[pmli]

@pmli, is there a concrete benefit to have the parameter in the matrix equation solver interface? If not, I would not see much reason to add a mu everywhere. For comparison, bindings.scipy.apply_inverse also does not support parameters.

Right, that's something I'm not sure about. I was confused that apply methods bound to operators all support parameters, but bindings.scipy.apply_inverse does not.

I guess one difference between matrix equation solver accepting and not accepting parameters is when assemble is called. Is there a significant difference between

Amu = A.assemble(mu)
Emu = E.assemble(mu)
sEmA = s * Emu - Amu
V = sEmA.apply_inverse(U)

and

aEmA = s * E - A
V = sEmA.apply_inverse(U, mu=mu)

?

[sdrave]

No, there should not be any difference. (LincombOperator.assemble calls assemble on all contained operators first.) In general, I see the code in pymor.bindings` as backend code which should not have to worry about parametrization.

[pmli]

Ok, good. I would ask what about algorithms.lyapunov, but I see that also algorithms.genericsolvers.apply_inverse does not accept parameters, so I guess there really is no motivation for matrix equation solvers to accept parameters.

[pmli]

@sdrave What do you think about adding an assemble method to models, which would return a non-parametric model with all operators assembled? I would use it for non-parametric reductors, e.g. BTReductor and IRKAReductor.

[sdrave]

@pmli, such a method would surely be useful. One downside is, that similar to reductors we would have a problem with subclassing: basically, everyone subclassing a model would have to implement assemble. Also, if we had a DuneLTIModel which constructs itself from an ini-file, there would be no way for the assembled model to be again a DuneLTIModel. Not sure what the right approach would be.

An alternative might be to implement assemble in the reductor and give the reductor the parameter as an init argument.

[pmli]

An alternative might be to implement assemble in the reductor and give the reductor the parameter as an init argument.

@sdrave In this case, should a non-parametric reductor return a parametric or a non-parametric ROM?

[sdrave]

A non-parametric ROM i guess.

[pmli]

@sdrave I could use some help with creating a matrix-based parametric LTIModel. For example, if I have A0, A1, B, C as NumPy/SciPy matrices, how to create A0 + mu * A1 and LTIModel(A0 + mu * A1, B, C) with scalar parameter mu?

[sdrave]

@pmli, basically:

A = LincombOperator([A0, A1], [1, ProjectionParameterFunctional('foo', ())])

This will make A depend on one scalar parameter named 'foo'. (I know ProjectionParameterFunctional isn't a great name ...)