ruff fixes

[DanielYang59]

Summary

• test_wandb_log_frequency use temporary path to avoid creating files locally

Relocate to another PR

• Build against NumPy 2.0, https://numpy.org/doc/stable/dev/depending_on_numpy.html
• Ruff NPY201 rule run seems to pass (https://numpy.org/doc/stable/numpy_2_0_migration_guide.html):

  Many of the changes covered in the 2.0 release notes and in this migration guide can be automatically adapted in downstream code with a dedicated Ruff rule, namely rule NPY201.

[DanielYang59]

@janosh Can you please approve the workflow? Thanks!

[DanielYang59]

Thanks! I believe the test failure is owing to the lack of support of NumPy 2.0 from pymatgen's side materialsproject/pymatgen#3953. Not sure what's the best practice at this moment as pymatgen is waiting for chgnet to support NumPy 2.0 too materialsproject/pymatgen#3894 (comment) (perhaps use np2 for build system and np1 for runtime dependency?)

[janosh]

Pymatgen should go first and ignore failing chgnet tests

[DanielYang59]

Yes I just realized the same, pymatgen should build against np2 first :) And it would be compatible with np1 at runtime

[DanielYang59]

@janosh It looks like you have to approve the workflow again for some reason?

[janosh]

until your first PR to a repo is merged, workflows need to be re-approved on every commit. it's quite annoying

[DanielYang59]

Hi @janosh if i remember correctly, this cannot be merged until a new release of pymatgen is issued.

[janosh]

@DanielYang59 thanks for the reminder. pymatgen v2024.9.10 should be on PyPI in a few minutes

[DanielYang59]

@janosh Have to ping you to approve the workflow (again), hopefully no test fails this time

[DanielYang59]

@janosh Should be good this time :)

[DanielYang59]

perhaps this signals that one of the dtype changes in make_graph is still platform dependent or needs to be reverted?

Concur, we should focus on inferred (implicit) types, i.e. np.array([0, 1]) whose type would still be platform dependent.

Instead of just changing the type in tests, we should also update the code where int is expected and automatically cast the type to int64. Otherwise users might still experience issues if they don't explicitly declare types.

However, I'm not familiar with the code base so if @BowenD-UCB could give a hand that would very helpful.

Sorry about the delay on the PR, been a bit busy lately.

It has not been delayed at all :) pymatgen just unblocked this.

[DanielYang59]

@janosh I reverted all (I believe) numpy related change from this PR, and relocate NumPy v2 migration to another PR as it turns out there's more debugging needed than I expected.

Might need to replace the labels for this PR

[janosh]

we should probably add a seed kwarg to Structure.perturb that's simply passed into np.random.default_rng(seed=seed) over in pymatgen

[DanielYang59]

That's a good point, especially with the generator implementation.

I didn't realize this downside before but it turns out with the new generator implementation every rng is a isolated instance, making it impossible to set a global seed and control all random states (or it's just me unaware of that).

[janosh]

thanks @DanielYang59! 👍

[DanielYang59]

No problem, thanks for merging this.