Tests for radiative cooling approximation icooling=9

[alisonkyoung1]

Description:
This introduces tests for icooling=9 and ieos=24. First there's the test test_eos_stam.f90 that checks the read and interpolation of the EOS/opacity table. Second, there's a new Github workflow to run a collapsing sphere test and compare the evolution to a reference result.
Additionally, there's an improved table search in eos_stamatellos.f90.
(Lots of files have changed because I ran the bots and the year updated to 2026.)

Components modified:

• [x ] Setup (src/setup)
• Main code (src/main)
• Moddump utilities (src/utils/moddump)
• Analysis utilities (src/utils/analysis)
• Test suite (src/tests)
• Documentation (docs/)
• Build/CI (build/ or github actions)

Type of change:

• Bug fix
• Physics improvements
• Better initial conditions
• Performance improvements
• Documentation update
• Better testing
• Code cleanup / refactor
• Other (please describe)

Testing:
Checked the results of the test.

Did you run the bots? yes

Did you update relevant documentation in the docs directory? no

Did you add comments such that the purpose of the code is understandable? yes

Is there a unit test that could be added for this feature/bug? n/a

[alisonkyoung1]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces tests for the radiative cooling approximation, including a new test for EOS table interpolation and a GitHub workflow for a collapsing sphere test. The changes also include performance improvements in the table search algorithm. My review focuses on improving code clarity, robustness, and maintainability. I've identified some duplicate entries in the AUTHORS file, potential issues in a new test script, and opportunities for code refinement in the updated modules, such as removing magic numbers and commented-out code.

[alisonkyoung1]

I can't figure out why these tests are failing with a divide by zero error...?

[alisonkyoung1]

@danieljprice The files for running the radiative cooling approx test workflow are currently in /data/cooling/
The other workflows seem to download the setup files etc from elsewhere so I thought I'd wait and ask you where these should go.

[danieljprice]

Hi @alisonkyoung1 how big are the files required for cooling? If more than a few hundred kb then they can/should be hosted on Zenodo. Are they already committed to the git repo though?

For the write_dump crash I think the issue is how the array is passed, it's better to use the syntax below where we send the whole array but give an argument for the index which should be written to the dump:

       if (eos_is_non_ideal(ieos) .or. (.not.store_dust_temperature .and. icooling > 0)) then
          call write_array(1,eos_vars,eos_vars_label,npart,k,ipass,idump,nums,nerr,index=itemp)
       endif

Divide by zero error is probably an uninitialised variable bug? With DEBUG=yes we initialise all reals and ints to NaN and then flag floating point exceptions to check where a variable is used without being set.

[danieljprice]

the test failure looks like an accounting issue, since I cannot see a failure, just looks like ntests has been incremented but not npass (should be incremented by calling update_test_scores) ?

[alisonkyoung1]

Hi @danieljprice, the files are small, <30kb. I did commit them already but happy to move them if need be.
And yes, I was thinking that too. Will check!

[alisonkyoung1]

Hi @danieljprice, we're down to just a couple of errors now. As far as I can tell, these aren't related to things I've changed, so I'm not sure what's going on.
19/32 - error reading MESA file
21/32 - as above
24/32 - aocc compiler error ...?
25/32 , 29/32 - MESA
I'm getting test fails on quartic.f90 too on my laptop.

[danieljprice]

Hi @alisonkyoung1,

• we fixed the aocc problem on master, this was caused by an update to aocc, can be fixed on your p-r by merging master-> your branch
• the error reading MESA is just a download issue and can be fixed by re-running failed jobs
• for 30kb files already committed I'd suggest just to leave them in the repo, otherwise we have to rewrite history which is a mess

[danieljprice]

however the SETUP=starcluster test failure is real. The test here is that phantomsetup should run with default options (pressing enter to any questions) and successfully produce a .in file. Phantom itself must also be able to run for one timestep including with DEBUG=yes to check for uninitialised variables. So should be able to reproduce this with:

make SETUP=starcluster DEBUG=yes setup
./phantomsetup blah
./phantomsetup blah
./phantom blah.in