This is a good point, did you consider it any further yet? At the moment I would tend to leave the invert_options mostly as they are, since it still makes sense to provide the knowledge of how to invert an operator together with the operator. It would then be possible to obtain a new operator by calling
If the naming is too confusing we could also rename them to available_invert_options and store the current ones in _invert_options or _current_invert_options, but I do not have a strong opinion there.
Thinking about it, I believe that invert_options is not such a great name, anyhow. I would propose to use solver_options for the options in use (I could also live with apply_inverse_options) and available_solver_options (or available_apply_inverse_options) for what is currently named invert_options.
From my point of view, it would also be attractive to remove the current invert_options completely from pyMOR. At least for constructions like LincombOperator it would be very hard to provide a list. For everything NumPy-based, the defaults in pyMOR are already a good documentation of what is available. I myself have never used invert_options and I had no fun implementing it ..
I agree on the first point (and would probably suggest apply_inverse_options, if we go down that route). I also see the burden of implementing these options and could live with their removal, given that we have not used them before.
However, I still think that it could become very important to have different versions of the same operator with different apply_inverse_options. If we dropped those and went the default route, do you see a way to still achieve that?
We could let an operator have its own options, if he was created with_ them. However, it could become unclear then why this operator behaves differently than the same one without specified options (thus taking the default).
We could also let each operator hold solver_options or apply_inverse_options. If those are set to default, the defaults from defaults will be used, and other options otherwise.
These are just some thoughts and suggestions, though ...
No description provided.
The text was updated successfully, but these errors were encountered: