Successive constraints method

[HenKlei]

Since @sdrave was complaining about the missing successive constraints method for a few times now, I started implementing something in that direction. However, this is far from being finished at the moment.

[sdrave]

Seems like I should complain more often ... Maybe we can discuss things offline next week?

[HenKlei]

Seems like I should complain more often ... Maybe we can discuss things offline next week?

Yes of course, let's discuss this next week.

[HenKlei]

@sdrave Do you think you will have time to discuss and look into this before the release?

[HenKlei]

~~Note to myself: Use pyMOR's eigs-method instead of numpy.~~ Done.

[HenKlei]

It would be great if you could take a look at this @sdrave when you find time.

[HenKlei]

The pipelines are failing due to a very old scipy version (1.5.4) where the 'highs' method (which is now the default) was not available as solver of a linear program in scipy. 'simplex' would be a method that is supported in probably all versions but is considered legacy in current versions. So maybe also not the best option to use that one as default.

How about pinning scipy to >=1.7.0?

[sdrave]

The pipelines are failing due to a very old scipy version (1.5.4) where the 'highs' method (which is now the default) was not available as solver of a linear program in scipy. 'simplex' would be a method that is supported in probably all versions but is considered legacy in current versions. So maybe also not the best option to use that one as default.

How about pinning scipy to >=1.7.0?

Debian oldstable has 1.6.0. I think that should be enough as well? Any reasons to require 1.7?

[HenKlei]

The pipelines are failing due to a very old scipy version (1.5.4) where the 'highs' method (which is now the default) was not available as solver of a linear program in scipy. 'simplex' would be a method that is supported in probably all versions but is considered legacy in current versions. So maybe also not the best option to use that one as default. How about pinning scipy to >=1.7.0?

Debian oldstable has 1.6.0. I think that should be enough as well? Any reasons to require 1.7?

You're right, 1.6.0 would be sufficient.

[HenKlei]

Is the scm module in algorithms what you anticipated @sdrave? I will look into your further remarks in the next days.

[HenKlei]

I am not entirely sure what kind of example for the estimation of the coercivity constant you have in mind @sdrave and what kinds of plots/results you would like to see. Maybe you can have a short look if the updated demo goes into the right direction.

[github-actions[bot]]

This pull request modifies pyproject.toml or requirements-ci-oldest-pins.in. In case dependencies were changed, make sure to call

make ci_requirements

and commit the changed files to ensure that CI runs with the updated dependencies.

[github-actions[bot]]

This pull request modifies pyproject.toml or requirements-ci-oldest-pins.in. In case dependencies were changed, make sure to call

make ci_requirements

and commit the changed files to ensure that CI runs with the updated dependencies.

[HenKlei]

CI is passing now @sdrave ;-)

[github-actions[bot]]

This pull request modifies pyproject.toml or requirements-ci-oldest-pins.in. In case dependencies were changed, make sure to call

make ci_requirements

and commit the changed files to ensure that CI runs with the updated dependencies.

[github-actions[bot]]

This pull request modifies pyproject.toml or requirements-ci-oldest-pins.in. In case dependencies were changed, make sure to call

make ci_requirements

and commit the changed files to ensure that CI runs with the updated dependencies.

[HenKlei]

Thanks @sdrave, this will be merged then.

[sdrave]

@HenKlei, could you also update the first PR comment and make it a bit more informative?

[HenKlei]

Seems like you have to give green lights @sdrave :-D