Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameterizing input-output models #626

Merged
merged 9 commits into from Jun 12, 2019
Merged

Parameterizing input-output models #626

merged 9 commits into from Jun 12, 2019

Conversation

pmli
Copy link
Member

@pmli pmli commented Mar 11, 2019

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.

@pmli pmli added sys-mor pr:change labels Mar 11, 2019
@pmli pmli added this to the 2019.2 milestone Mar 11, 2019
@renefritze
Copy link
Member

@renefritze renefritze commented Mar 11, 2019

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

@sdrave
Copy link
Member

@sdrave sdrave commented Mar 11, 2019

@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
Copy link
Member Author

@pmli pmli commented Mar 11, 2019

@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
Copy link
Member

@sdrave sdrave commented Mar 11, 2019

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
Copy link
Member Author

@pmli pmli commented Mar 11, 2019

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 pmli self-assigned this Mar 11, 2019
@pmli
Copy link
Member Author

@pmli pmli commented Mar 14, 2019

@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
Copy link
Member

@sdrave sdrave commented Mar 14, 2019

@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
Copy link
Member Author

@pmli pmli commented Mar 14, 2019

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
Copy link
Member

@sdrave sdrave commented Mar 14, 2019

A non-parametric ROM i guess.

@pmli
Copy link
Member Author

@pmli pmli commented Mar 29, 2019

@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
Copy link
Member

@sdrave sdrave commented Apr 1, 2019

@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 ...)

@pmli pmli force-pushed the parametric-lti branch 3 times, most recently from 58e2a28 to 6c5553f Compare Jun 6, 2019
@pmli pmli marked this pull request as ready for review Jun 6, 2019
@pmli pmli requested a review from sdrave Jun 6, 2019
sdrave
sdrave approved these changes Jun 11, 2019
@pmli pmli merged commit 328bc46 into master Jun 12, 2019
7 checks passed
@pmli pmli deleted the parametric-lti branch Jun 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants