pymepack binding for gem

[almalejko]

This PR adds a binding to python-mepack (pymepack) backend lyapunov solvers.

The binding offers the option for iterative refinement and shows better performance when compared to slycot.

NOTE: branch for this pull request is based on the branch for #2167 in the forked project.

[github-actions]

Mirroring external branch in external_pr_2166

[almalejko]

pre-commit.ci autofix

[pmli]

At a quick glance, everything necessary to use pymepack seems to be here. The question is how to test it in CI. How do you install pymepack? For the CI, it would be nice if it was possible to install pymepack using pip from PyPI (i.e., pip install pymepack).

[pmli]

This should be reverted.

[almalejko]

pymepack-0.9.1-cp38-cp38-manylinux_2_31_x86_64.zip
@pmli , please, use this wheel to pip install the pymepack project.

[pmli]

[pymepack-0.9.1-cp38-cp38-linux_x86_64.zip](https://github.com/pymor/pymor/files/12474200/pymepack-0.9.1-cp38-cp38-linux_x86_64.zip) Please, change the extension to .whl and use pip install to install pymepack

For some reason, I got the above comment by email, but I don't see it in this thread. But, anyway, installing from PyPI would be nicer, but I guess installing from URL could also work in CI.

[almalejko]

For some reason, I got the above comment by email, but I don't see it in this thread. But, anyway, installing from PyPI would be nicer, but I guess installing from URL could also work in CI.

@pmli , the wheel w/o dependencies, so I deleted the comment.
Please, use the manylinux wheel that I have attached to verify the changes. Pymepack is not yet available at PyPI.

[pmli]

I can confirm that the pymepack tests pass. However, as I said, it would be good for us to have wheels on PyPI for all Python versions from 3.8 to 3.11.

[almalejko]

I can confirm that the pymepack tests pass. However, as I said, it would be good for us to have wheels on PyPI for all Python versions from 3.8 to 3.11.

@pmli , the PR is ready for review, pymepack is available at PyPI: https://pypi.org/project/pymepack/

[github-actions]

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.

[pmli]

I tried updating the requirements, but running DOCKER=podman make ci_requirements produces the error:

  ERROR: Cannot install dune-xt[visualisation]==2022.5.3, pymor (pyproject.toml), scipy==1.5.4 and scipy>=1.5.4 because these package versions have conflicting dependencies.
Discarding scipy==1.5.4 (from -r requirements-ci-oldest.txt (line 505)) to proceed the resolution
  ERROR: Cannot install dune-xt[visualisation]==2022.5.3, pymor (pyproject.toml), scipy==1.5.4 and scipy>=1.5.4 because these package versions have conflicting dependencies.

@sdrave, any ideas?

[sdrave]

I tried updating the requirements, but running DOCKER=podman make ci_requirements produces the error:

  ERROR: Cannot install dune-xt[visualisation]==2022.5.3, pymor (pyproject.toml), scipy==1.5.4 and scipy>=1.5.4 because these package versions have conflicting dependencies.
Discarding scipy==1.5.4 (from -r requirements-ci-oldest.txt (line 505)) to proceed the resolution
  ERROR: Cannot install dune-xt[visualisation]==2022.5.3, pymor (pyproject.toml), scipy==1.5.4 and scipy>=1.5.4 because these package versions have conflicting dependencies.

@sdrave, any ideas?

No idea why the error message has to be so bad and I don't understand what dune-xt hast to do with it. But requirements-ci-oldest-pins.in pins scipy to 1.5.4. pymepack apparently has scipy>=1.6.0.

[github-actions]

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.

[sdrave]

The CI failures seem due to the fact that the pymepack wheel has been compiled for a newer numpy than the one we test with. For binary wheels it is generally a good idea to depend on oldest-supported-numpy. I'm not sure whether this issue can be resolved before hard freeze.

[pmli]

I'm not sure whether this issue can be resolved before hard freeze.

True. Let's postpone this.