Prepare for NumPy 2.0

[paulromano]

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

• I have performed a self-review of my own code
• I have run clang-format (version 15) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[nelsonag]

I have reviewed the changes provided and performed greps for all items on the numpy 2 migration guide.
I only have one comment, which is not necessary for merge as it doesn't affect 2.0 compatibility:

• numpy 2.0.0 deprecates np.trapz which we use twice within our codebase. We should consider moving to scipy.integrate.trapezoid instead.

One observation that does not need to be incorporated, as it doesn't effect numpy 2.0.0 compatibility, is that np.trapz is deprecated

[paulromano]

@nelsonag Thanks for the careful review! I've just added a commit replacing np.trapz with scipy.integrate.trapezoid.

[paulromano]

@nelsonag Do you have any further requests on this PR?

[eepeterson]

@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.

[paulromano]

@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.

[paulromano]

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.

[paulromano]

@eepeterson OK, just took care of the NPY002 warnings from ruff ✔️

[eepeterson]

Thanks @paulromano! will merge after the green light