Dropping support for numpy<2 ?

[tlunet]

I'm currently adding a new feature in qmat, to allows duplicates in interpolation points and handle that automatically (see current PR). This should be particularly useful for a new version of PFASST I'm investigating, that uses some global diagonal SDC on the coarse mesh, but requires also a global restriction operator that will have duplicates on the fine points.

To simplify the implementation in qmat, I used the numpy.unique_all function, which is only available with numpy>=2. However, currently pySDC still support numpy>=1.15.4, so I wonder ....

Can numpy requirement in pySDC be increased to numpy>=2, as this major release dates from 1 year ago already and had some non-backward compatibility changes that will make supporting prior versions more and more difficult ...

[pancetta]

numpy>=2 works with Python 3.9+, right?

[tlunet]

Yes, that's what I noticed. Python 3.8 still has some numpy<2 as latest version, which made the qmat test fail, hence I dropped it (but still, imposed numpy>=2)

But Python 3.9+ uses some numpy>=2 already as latest version

[pancetta]

Do you see any drawbacks in droping numpy v1 support @brownbaerchen ?

[brownbaerchen]

Seems fine to me. However, the documentation of numpy.unique_all says that this just makes use of numpy.unique slightly easier.
Personally, I would stick to the more compatible one. But I am totally fine with dropping Python 3.8 and numpy < 2.

[tlunet]

It's not only that : numpy.unique_all also makes the result of numpy.unique_counts, numpy.unique_inverse, etc ... functions (see Release Notes, which are used in the new feature from qmat.

So numpy v1 support would require to call those manually, which would make the code more complex

Sorry, spoke too fast ... I could use numpy.unique instead, that won't change the code that much ...

[pancetta]

Nevertheless, I'm ok with dropping Python 3.9 and numpy 1.x. If this makes life easier and code better, then go ahead.

[tlunet]

Can you add that to your current PR @brownbaerchen ? Should be just a small modification in the pyproject.toml file ...

[brownbaerchen]

Seems I would need to build a new Docker image for the libpressio tests with numpy version 2 to have the entire pipeline run on numpy v2.
This seems a lot more work than for you to use np.unique. I remember a lot of exasperation when making this image in the first place. Building an image for intel architecture on my arm laptop takes many hours.
So, I see no compelling reason to drop compatibility with older versions at this time. If we can't do without version 2 at some point, I will build the new image. But I don't have time for that now.

[brownbaerchen]

Everyone fine with closing this issue as not planned for now?

[tlunet]

Fine ... just postponing the problem for now then 😉