Redshift alignment for simple rays

[claytonstrawn]

When using make_simple_ray to run sightlines with TRIDENT for AGORA Cosmorun, we discovered a weird behavior: components were biased towards negative velocities. This was true for all ion lines, at all redshifts, in all codes, so it was clear that it was some kind of TRIDENT behavior. (thinking this bias might be from "running out of components" is what prompted #195, though that ended up not being the case).

In fact, what's happening is intended behavior, not a bug, though I would argue users who make simple rays probably don't expect it to work the way it does. Since the line is created in a cosmological simulation, the redshift of the line is taken to be the dataset redshift. However, as the line travels, it goes to lower redshift, so the end of the line is "closer" to the observer. In other words, lines are blueshifted relative to the dataset. So, transforming the wavelengths into velocities using

v_ion = speedoflight*(wl/(line_rest_wl*(1+cosmo_redshift))-1)

gives all the lines a negative velocity of around 100 km/s, which has no relationship with the halo velocity. I tested this by comparing the same sightline twice, once with end and start reversed, and they were always mirrored around -100 km/s.

My solution was to change how sub_data[('gas','redshift')] is defined for each lixel by adding a new optional parameter redshift_align. The prior behavior would align the dataset redshift with the start of the sightline, no matter where it points or where the absorption takes place. I had two ideas for what this should be replaced with.

1. redshift_align = 'center' gives z>z_ds at the line start, z<z_ds at the line end, and z = z_ds at the midpoint of the line. If you make endpoints like I do, so they are supposed to pass by the galaxy at their midpoint, this will give the cgm aligned with the box, and slightly blueshift the "end" side and redshift the "start" side.
2. redshift_align = 'everywhere' gives z = z_ds for the whole duration of the line. (this was my first solution, because it was easier to figure out)

The pro of 'center' is that the line is more cosmologically realistic, the pro of 'everywhere' is that the velocities are more intuitively correct, i.e. velocity on this graph is the real LOS velocity of the cloud. The difference is minor but noticeable, but in any case it is much less significant than defaulting to 'start'. I added both as options here. If the user passes in some other argument, I figured "everywhere" is the most simple option, so I added a warning and used that.

I don't think this makes sense for complex_rays, so I didn't add it to that function, though would be happy to discuss that if anyone wants. I don't understand how complex_rays work nearly as well, and have never made one.

[claytonstrawn]

This change wasn't actually meant to be part of the PR, was just a random bug fix. I don't remember exactly the problem here, but if there is a more elegant solution to this I'm happy to change it

[coveralls]

Pull Request Test Coverage Report for Build 33f2556c-6e17-4592-8920-3a0426b6c050

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 48 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.2%) to 75.508%

---

Files with Coverage Reduction	New Missed Lines	%
/home/circleci/trident/trident/ray_generator.py	9	89.25%
/home/circleci/trident/trident/light_ray.py	39	86.68%

Totals
Change from base Build b3b725de-e97a-4358-8225-f0648498ecac:	-0.2%
Covered Lines:	1748
Relevant Lines:	2315

---

💛 - Coveralls