Skip to content

Conversation

SGeeversAtVortech
Copy link
Contributor

Add an example that illustrates how to implement a fallback option in case a solver fails.

@SGeeversAtVortech SGeeversAtVortech force-pushed the example_fallback_option branch 3 times, most recently from 9690a0b to 65ca439 Compare April 22, 2025 14:43
Illustrate how to fallback to a different solver in case
the last solver fails.
This includes an example with goal programming
where the fallback option is applied for each priority.
:pyobject: Example.optimize
:lineno-match:

Here, we iteratore over the solvers `ipopt` and `highs`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iteratore --> iterate


def __init__(self, **kwargs):
self.solver = None
super().__init__(**kwargs)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this constructor can be removed as it does nothing?


def __init__(self, **kwargs):
self.solver = "ipopt" # Solver, by default ipopt.
super().__init__(**kwargs)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this constructor be removed?

until one of them succeeds.
* Let your main optimization problem class also inherit from ``MultiRunMixin``.
It is important that ``MultiRunMixin`` comes after ``GoalProgrammingMixin``
in the inheritance list.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be an argument for including a dedicated `MultiRunMixin' in the library after all. @jackvreeken thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it's fine for now. Order of inheritance is important the other way around as well (with a "helper" in run_optimization_problem). I don't like "solver workarounds" in the core, but if it proves really useful we can always decide to include it in the library at a later date.

@jarsarasty jarsarasty added discussion needed documentation Improvements or additions to documentation and removed discussion needed labels Jun 16, 2025
@jarsarasty
Copy link
Contributor

@Ailbhemit ,

Could you please address Jorn's comments?

@jarsarasty jarsarasty added this to the 2.8 milestone Jul 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants