ValueError When Using Different yml Config Files

[MAKaral27]

Summary

I am hitting a convergence-time crash inside TARDIS while trying to run simulations for a standalone plotting script for the GSoC “TARDIS Setups Generated Plots and Gallery” idea.

The failure appears to occur inside MCRadiationFieldPropertiesSolver.estimate_jblues(), where the Monte Carlo line estimator has a different number of cells than the geometry/radiation-field arrays.

The crash happens during run_tardis(...) before the plotting functions are reached.

Reproduction

Call pattern

I am calling TARDIS in, as far as I can tell, a standard way:

sim = run_tardis(config=args.config, atom_data=args.atomic_data)

Script

You can try the exact script under this branch:

https://github.com/MAKaral27/tardis/tree/repro-jblues-shape-mismatch
(This is also the same script as was used in issue #3508, so I will leave a comment there referencing this branch. It is located under /docs)

Example command 1

(separate issue with this atomic data file, had to be deduplicated)
python Universal_SDec_LIV_plotter.py
--atomic_data aoife_atomic_data_levels_dedup.h5
--config ~helium_HM_19_recomb.yml

Example command 2

python Universal_SDec_LIV_plotter.py
--atomic_data kurucz_cd23_chianti_H_He_latest.h5
--config ~/downloads/29d.yml

Observed failure

For the helium recombination case, the debug output at the failure site was:

j_blue_estimator shape: (272164, 31)
volume shape: (55,)
line_list_nu shape: (272164,)
dilution_factor shape: (55,)

The resulting exception from exampåle 1 is:

ValueError: operands could not be broadcast together with shapes (272164,31) (55,)

And for example 2:

ValueError: operands could not be broadcast together with shapes (215976,36) (37,)

I monkeypatched estimate_jblues() to print the relevant shapes immediately before the failing multiplication. That is how I obtained the (272164, 31) versus (55,) mismatch above.

Expected behavior

Either the estimator/geometry cell counts should be the same during convergence, or TARDIS should raise a targeted diagnostic before the NumPy operation that is crashing it. Currently I do not even understand what is going wrong.

Environment

• TARDIS: 7dae5af
• Python: 3.13.3
• OS: Arch Linux

Fix

Having failed to identify the exact point of failure, I honestly don't know how to fix this. It would be great if someone else could have a look.

[Aaryan-Dadu]

Hey @MAKaral27,
I had also encountered similar scenario while researching over the codebase, the thing is that the config is added 3 years earlier in 2023 so the researcher who would have been working on this would have tardis version which would be atleast 3 years older so during this period of 3 years code has evolved and in some case lacks backward compatibility and thus is no longer compatible with the older configs and as these configs present in tardis-setups are used in published papers so these config files must not change as per my knowledge. So if you want to run this config it's better to use an older state of tardis for now. I did it like this,

Tardis : b3bc761 (April 2023)

I tweaked my script in #3479 to Demo.ipynb to make it run this version.
My run didn't fully completed but it has nothing to do with any issue in tardis, during the last iteration my system's memory exhausted so I had to interrupt it.

[MAKaral27]

Thanks @Aaryan-Dadu, that gives me some time frames to work with. I'll do some digging over the weekend and see if I can find the exact breaking point, and see if I can't find a simple patch to make the old configs backwards compatible