Transfer function API and integration fixes

[fjebaker]

Attempt to fix different problems with the transfer functions.

The seam in this figure corresponds to the bin edge $g^\ast \in [0, h]$ and $g^\ast \in [1-h, 1]$. I tried a few different schemes to resolve this, but I think it's a combination of getting the timing wrong, and also the flux in the bin edges being too low with that Dauser approximation?

[phajy]

Very interesting. What value of $h$ are you using (and does it vary with $r_e$)? Can you quantify the glitch, e.g., by plotting the flux contribution / time as a function of $g^\star$? Might help see if the problem is mainly with flux rather than time.

It looks more prominent for $g^\star \simeq 0$ which is the locus of points with minimum redshift at each radius on the disc. I guess you could look at a disc image of $g$ and see how things look near the line $g^\star(r_e) = 0$ (i.e., $g_\text{min}(r_e)$ ), compared to $g^\star(r_e) \simeq h$.

Sorry, you've probably already tested a bunch of things. A slightly frustrating problem!

[fjebaker]

Hi @phajy! Thanks for the tips :)

In the above plot $h = 10^{-8}$, but the seam persists for any order of $h$.

The line profiles themselves seem to be unaffected (as in, summing along the time axis reconstructs the line profile correctly). It's definitely something to do with the binning and how the code is currently calculating which time bin to put the flux in, and less likely to do with the flux calculated in the edge.

A couple of observations

• everything to the left of the seam is the upper branch, everything to the right is the lower branch of both the $t$ and $f$ transfer function loops
• setting the edge contributions to zero removes everything between the brightest two ridges of the seam (here for a small span of radii)
  
  but the seam is still visible, further implying the problem is related to time bin calculations.