Python 3.13 support

[janosh]

pymatgen currently pins python<3.13

pymatgen/pyproject.toml

Line 24 in 5b997f7

requires-python = ">=3.10,<3.13"

[DanielYang59]

#4100 should unblock Python 3.13. But I'm a bit unsure about the CI failure (it wasn't there before), and I'm looking into it.

For some reason I cannot recreate that error (which looks like some float point number precision issue) on my Ubuntu machine running Python 3.13. Maybe be some dependency-related constant update or something.

______________________ TestEOS.test_numerical_eos_values _______________________

self = <analysis.test_eos.TestEOS testMethod=test_numerical_eos_values>

    def test_numerical_eos_values(self):
        assert_allclose(self.num_eos_fit.e0, -10.84749, atol=1e-3)
        assert_allclose(self.num_eos_fit.v0, 40.857201, atol=1e-1)
        assert_allclose(self.num_eos_fit.b0, 0.55, atol=1e-2)
>       assert_allclose(self.num_eos_fit.b0_GPa, 89.0[37](https://github.com/materialsproject/pymatgen/actions/runs/13219577081/job/36902930489?pr=4100#step:8:38)0727, atol=1e-1)

/home/runner/work/pymatgen/pymatgen/tests/analysis/test_eos.py:429: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

args = (<function assert_allclose.<locals>.compare at 0x7ff698cd6660>, array(88.82466552), array(89.0370727))
kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to tolerance rtol=1e-07, atol=0.1', 'verbose': True}

    @wraps(func)
    def inner(*args, **kwds):
        with self._recreate_cm():
>           return func(*args, **kwds)
E           AssertionError: 
E           Not equal to tolerance rtol=1e-07, atol=0.1
E           
E           Mismatched elements: 1 / 1 (100%)
E           Max absolute difference: 0.21240718
E           Max relative difference: 0.002[38](https://github.com/materialsproject/pymatgen/actions/runs/13219577081/job/36902930489?pr=4100#step:8:39)56
E            x: array(88.824666)
E            y: array(89.037073)

[janosh]

thanks so much for working on this @DanielYang59! 🥇 i see you're way ahead of me :)

the difference is small so maybe numerics and based on the doc string, the class being tested maybe should have been removed by now anyway. so i think safe enough to just update the expected value to the new actual

pymatgen/src/pymatgen/analysis/eos.py

Lines 511 to 541 in ee65dca

	class EOS:
	"""
	Convenient wrapper. Retained in its original state to ensure backward
	compatibility.
	Fit equation of state for bulk systems.
	The following equations are supported:
	murnaghan: PRB 28, 5480 (1983)
	birch: Intermetallic compounds: Principles and Practice, Vol I:
	Principles. pages 195-210
	birch_murnaghan: PRB 70, 224107
	pourier_tarantola: PRB 70, 224107
	vinet: PRB 70, 224107
	deltafactor
	numerical_eos: 10.1103/PhysRevB.90.174107.
	Usage:
	eos = EOS(eos_name='murnaghan')
	eos_fit = eos.fit(volumes, energies)
	eos_fit.plot()
	"""

[DanielYang59]

No problem at all!

the difference is small so maybe numerics and based on the doc string, the class being tested maybe should have been removed by now anyway

I would have a look at the reason and let me you (if I could find it), because currently it could be reliably recreated in CI. Maybe some constant get updated at certain version, probably similar to:

• Fix CI failure for io.exciting.inputs owing to scipy constant update #4244

[DanielYang59]

For some reason I cannot recreate that error (which looks like some float point number precision issue) on my Ubuntu machine running Python 3.13. Maybe be some dependency-related constant update or something.

Unfortunately I'm unable to recreate this issue nor find the reason after some time debugging, this is what I know so far:

• This error seems to be from fit which generates num_eos_fit.b0 as 0.5557256930400533 locally while being 0.5543999558833739 in CI

  pymatgen/tests/analysis/test_eos.py

  Lines 428 to 429 in 75afbb1

  	assert_allclose(self.num_eos_fit.b0, 0.55, atol=1e-2)
  	assert_allclose(self.num_eos_fit.b0_GPa, 89.0370727, atol=1e-1)

• The unit conversion factor is not the cause (I thought this might be the issue because scipy recently updated some constants):

  pymatgen/src/pymatgen/analysis/eos.py

  Lines 143 to 146 in 75afbb1

  	@property
  	def b0_GPa(self) -> FloatWithUnit:
  	"""The bulk modulus in GPa. This assumes the energy and volumes are in eV and Ang^3."""
  	return FloatWithUnit(self.b0, "eV ang^-3").to("GPa")

Above results are generated with the same Python (3.13.2), scipy(1.15.1) and numpy (1.26.4) versions, only noticeable difference is GitHub CI runner is now using Ubuntu 24.04 (my local machine is still Ubuntu 22.04)

As the result is generated with NumericalEOS.fit, very likely by optimization instead of finding exact solution, I guess such numerical error should be acceptable (the conversion factor is 160.21766339999996). So I would just further increase the absolute tolerance for now f11974f.