Behavior change in SpectrumGenerator between versions

[clairekope]

This came up while updating a package that relies on Trident that hasn't been updated since v1.2.3. Something between v1.2.3 and v1.3 changes how the SpectrumGenerator operates. I wasn't able to find an easy culprit when diff'ing the tags on GitHub but I'm confident the change is in SpectrumGenerator because the underlying ray data doesn't change, as illustrated below with the HI number density. Note that while these tests show v1.4.2 I did isolate the change to the release of v1.3.

Spectrum Comparison (the undesired behavior)

Number Density Comparison (ray unchanged)

Testing this Behavior

Installing Trident 1.2.3 should be straightforward if you first install Python 3.6, yt 3.6.1, and matplotlib 3.3.1.

If you want to install Trident 1.3, I first installed Python 3.8 and yt 4.0.3.

Finally, I've attached a minimally working example for this behavior. It uses the HiresIsolatedGalaxy sample Enzo dataset from yt.

trident_compare.py

[chummels]

Hi Claire. This indeed appears concerning. I don't recall any major changes to SpectrumGenerator in between those versions of the code, but I can take a closer look. One note is that there are a lot of changes that occur in yt between versions, and some of them adversely affect the behavior of trident. So it becomes a challenge trying to track down when some random change in yt breaks things in Trident. I have some answer tests in place to monitor changes like this, but they are not perfect.

I will try to reproduce this locally and see if I can find any obvious culprit in trident between the two versions.

Have you tried keeping the version of yt fixed while changing between version of Trident (that may not work), as that might provide some insight as to where the bad behavior arises.

Ahh the joys of interdependent software packages that are developed at very different rates of speed. :)

[clairekope]

Hi Cameron, so I was able to install Trident v1.3 alongside yt 3.6.1 by undoing some of the changes made to support yt 4. These changes were:

• switching from yt.loader import back to from yt.convenience
• adding dx, dy, and dz fields back into all_fields and data_fields in make_light_ray (line 525 of light_ray.py`)
• removing version constraints on yt and yt-astro-analysis in the package setup

When I make these changes, I reproduce the old behavior from 1.2.3. I suspect there's something about the removal of cell width information from light_ray.py that's the culprit.

[chummels]

Nice detective work! I think your hypothesis is likely correct. I wonder if you take the tip of trident and try to add dx, dy, dz fields (or some equivalent cell width) back into the light ray data fields if it will reproduce the desired behavior? If so, then it sounds like we could add a test to the code (to make sure it doesn't break in the future) and then everything is good? Also, I assume this is for SALSA to work with the tip of trident? Or is it another package? Thanks for your work on this.

[clairekope]

You're assumption is correct 😄 I'll go ahead and give this a shot, but I do wonder why it was removed in the first place? Are cell widths not supported for particle codes?

[chummels]

I don't recall why we did this, but I'm 99% sure it was to address some sort of underlying change in yt that probably broke trident. If you can identify the PR or the commit that gives the bad behavior (git bisect can help), then I can try to figure out why we did it and maybe come up with a solution that works for both grid and particle-based codes.

[clairekope]

Ok, so unfortunately it does look like the issue is with yt 3->4. I modified the tip of trident dev to save the cell widths to the ray and it still produced the "incorrect" spectrum. I'm not really sure what's the best path forward from here.