Run CI tests on all operating systems

[tovrstra]

This PR extends the continuous integration to Windows and macOS. The initial commit is minimal and more changes may be required to pass all tests, in line with issue #16.

[tovrstra]

@Ao-chuba With this PR the tests run on all operating systems, and there was one similar issue on macOS that required relaxing a threshold in the unit tests, similar to what you described but for a different test.

Based on these observations, it seems that OpenBLAS is causing the difference, or not? I don't have much experience with it. Do you know how it can be used in a GitHub Action?

[Ao-chuba]

@tovrstra
OpenBLAS is likely the cause. When NumPy is installed from PyPI, each platform gets a different bundled build as per what i know , Windows gets one compiled with MSVC, Linux uses a GCC build, and macOS might use Apple's framework instead of OpenBLAS entirely.
I am not 100% sure but i dont think There's no simple way to control the BLAS version in a GitHub Action when installing from PyPI. So I think relaxing the tolerances is a better approach here, and more maintainable than trying to force a specific BLAS setup.

[tovrstra]

@Ao-chuba I've included the NumPy and SciPy config outputs in the GH Action to allow for a better comparison with your local installation, see https://github.com/theochem/tinydft/actions/runs/24385878928/job/71219495810?pr=17#step:6:1

Can you compare the outputs of the following commands with the ones from the CI to see where they differ?

python -c "import numpy; numpy.show_config()"
python -c "import scipy; scipy.show_config()"

The CI on Windows also uses a NumPy linked to OpenBLAS, so there should be another explanation for the discrepancy. Thanks!

[Ao-chuba]

@tovrstra
My configs are identical to CI , same OpenBLAS versions (0.3.31 for NumPy, 0.3.30 for SciPy), same MSVC for NumPy, same GCC/Strawberry for SciPy, same 32/64-bit integer layout. The only difference is Python 3.12 locally vs 3.14 in CI.
Since both use DYNAMIC_ARCH, my best guess is that ,
it comes down to the CPU itself. My machine is AMD Ryzen (Family 25, Model 80) while the CI maybe intel or someother . Same OpenBLAS binary, different SIMD code path selected at runtime, tiny floating point difference right at the tolerance boundary.

[tovrstra]

Thanks for bringing up CPU architecture. I don't have access to that specific CPU, but I tried a few other ones for comparison, all with Linux.

• On Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz, I get a similar problem with the assert statement on tests/test_tinygrid.py:116.
• On AMD EPYC 7552 48-Core Processor, no problems
• On 13th Gen Intel(R) Core(TM) i7-13700K, no problems
• On Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, no problems
• On Intel(R) Core(TM) i5-9500 CPU @ 3.00GHz, no problems
• On Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, no problems

It seems fine most of the time, except for some unlucky CPUs, so there is no hope that we can catch such problems in a GitHub Action systematically. I guess the best we can do is carefully increase thresholds and add comments for which CPU architecture the threshold was increased. It's probably also good to add a note to the README that this is a known issue.

Can you install the cpuinfo package from PyPI, run this script and post the line starting with Brand Raw:? This is a standardized and detailed cross-platform CPU description. Thanks.

[Ao-chuba]

@tovrstra
Brand Raw: AMD Ryzen 5 5600H with Radeon Graphics
That's a Zen 3 laptop chip different from the AMD EPYC 7552 (Zen 2) you tested, so that explains why EPYC was fine but mine isn't. The floating point behavior can differ even between AMD generations. So yes the plan of relaxing thresholds with comments sounds good to me too.

[tovrstra]

Thresholds were updated with comments on CPUs. @Ao-chuba Can you confirm that all tests pass on your laptop too?

[Ao-chuba]

@tovrstra
test_hydrogenic_op[6-1] is no longer failing .All 215 tests passed this time!

[tovrstra]

Thanks. Time to merge...