reconsider 'options' parameter for OperatorInterface.apply_inverse

[sdrave]

No description provided.

[ftalbrecht]

Agreed. We should drop the argument for usual operators and use the with_ method to create a new operator with different options. How to proceed with LincombOperator is yet unclear...

[sdrave]

Ok, so this is decided. I guess, there should be a standardized attribute which holds the options that are being used? How should we name it and what happens with invert_options?

[ftalbrecht]

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

new_op = op.with_(op.invert_options['bicgstab'])

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.

[sdrave]

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

[ftalbrecht]

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

[sdrave]

@ftalbrecht, I only propose to remove the list of available options. The options set for a specific Operator should be available and settable during creation of the operator.

[sdrave]

Another question is how to proceed with least squares solvers.

[sdrave]

See changes in #184, #185.