openmc-dev
Prepare for NumPy 2.0
Description
NumPy is going to be making a major release (2.0) soon that is backwards incompatible. Thankfully, there's very little we need to change in OpenMC in order to prepare for the 2.0 release. The only thing that needed to be changed was to replace np.string_ with np.bytes_ as mentioned in the migration guide.
Checklist
- [x] I have performed a self-review of my own code
- [x]
I have run clang-format (version 15) on any C++ source files (if applicable) - [x] I have followed the style guidelines for Python source files (if applicable)
- [x]
I have made corresponding changes to the documentation (if applicable) - [x]
I have added tests that prove my fix is effective or that my feature works (if applicable)
@nelsonag Thanks for the careful review! I've just added a commit replacing np.trapz with scipy.integrate.trapezoid.
@paulromano this looks good to me so far. I think the small amount of Cython used in the repo should be fine because it was using Cython > 3.0. I did go through the other Ruff rules for numpy after looking through the migration guide and noticed we are using legacy functions from numpy.random in the Python API and it's recommended to update to using numpy.random.Generator if we don't need these to be exactly the same. The offending lines can be found with Ruff rule NPY002. Let me know if you want to tackle those here or not. If not I think this is good to go.
@eepeterson Thanks for pointing that out about numpy.random. I played around with it a little and can't get it to produce the same random numbers, so I think it's probably best if we handle that as a separate PR. As is, the legacy RNG stuff does still work with numpy 2.0 so it's not an imminent issue.
Actually jk, if I use numpy.random.RandomState it does produce the same random numbers. I'll incorporate that in this PR. If we want to change the default RNG used, that we can do as a separate PR.
@eepeterson OK, just took care of the NPY002 warnings from ruff :heavy_check_mark: