Add option to rescale temperature before extracting skewers
Closed this issue · 11 comments
From a given snapshot, we can make a T-rho scatter plot, and fit values for (T_0, gamma).
In principle, we could rescale the temperature in post-processing, and generate multiple realization of the same set of skewers but for diffenent values of (T_0, gamma). That would be great since it would allow us to study more thermal history models, without needing to re-run simulations.
Say our initial snapshot has values (T_0, gamma). If we want to have a different set of values (T_0^\prime, gamma^\prime), we can trivially compute a correction factor f(rho) that we can use to compute a new temperature field for all particles in the box:
T^\prime(x) = f(\rho(x)) T(x)
We can then use these new values to extract new skewers.
There are several unknowns here, for instance whether we should apply the transformation to all particles, or only to those particles that have rho < rho_max, or similarly T < T_max. Without this, it is possible that we end up assigning pretty extreme (unphysical?) values of temperature to some very high-density particles. May be one can use a smooth function to transition from f(\rho) to 1.
@Chris-Pedersen, @sbird, @keirkwame - do you want to talk about this at some point?
I had a quick chat with Matt McQuinn, and he mentioned that this should work, but that we might want to "tilt" only the temperature for particles that are in the "power law region", something similat to what I was mentioning before with rho < rho_max.
He mentioned that rho_max should probably change with redshift, and that we could get some inspiration / references from his 2014 paper: https://arxiv.org/pdf/1401.0737.pdf
Hi @sbird, @Chris-Pedersen, I was looking at the best way to proceed to do this.
The easiest option is to do the temperature change before calling the C routines, i.e., we would call _read_particle_data, modify the temperatures, and then call _do_interpolation_work.
The problem is that there are different functions that call these, like:
- _vel_single_file
- _temp_single_file
- _densweightdens
- _interpolate_single_file
I'm worried that we'll add a bit of noise if we add options for all these functions to rescale the temperature, since we would also need to specify how exactly we want to rescale it.
You'll want to subclass the Spectra class and add a class constructor parameter to rescale the temperature. You could alternatively do it by subclassing GasProperties and deal with the rescaling in that.
I'm always worried about double inheritance, since we might want to rescale the temperatures both for GriddedSpectra and "normal" Spectra. Should we then make GriddedSpectra inherit SpectraThatCanRescaleTemperature?
Sure, or you can have a separate class GriddedSpectraThatCanRescaleTemperature that subclasses SpectraThatCanRescaleTemperature to inherit both Spectra and GriddedSpectra. There is no law against deep class hierarchies :)
I don't know much about the issue in Python, but in C++ there are many "recommendations" to avoid the diamond problem... https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem
The alternative would be to just add the feature in Spectra, just like "rescale_mean_flux" is an option there.
It's somewhat easier in python - you just ensure that your inheritance diagram doesn't contain a loop and you're fine. You could also add it as a method argument, but I would still subclass because it's a fairly specialised feature, so it belongs in a separate place. Spectra is too long already (adding rescale_mean_flux to the main class was a compromise and one I am likely to regret).
Take a look at the code in the ratenetwork branch . I made the GasProperties class an option to Spectra, so that it can be swapped out easily. It also seems that I started implementing temperature rescaling (by changing the internal energy) in ratenetworkspectra.py but didn't finish. Feel free to complete the implementation and add it there. We could also implement it separately, but probably more consistent not to: we want changing the temperature to also change the neutral fraction a little.
Hi @sbird - I'll take a good look at it next week, once back at UCL. For now, I noticed that the documentation of the constructor in spectra.py seems outdated, since it does not mention gasprop_args.
This is implemented now