websky-cita / xgpaint.jl

fast forward simulations of extragalactic foregrounds

XGPaint.jl

XGPaint.jl paints maps of extragalactic foregrounds using halo catalogs. Please read the documentation.

xgpaint.jl's Issues

allow option to store CIB flux source catalog

If we release maps, we should store the fluxes! It should just be copy pasting some code from the radio sources (which already can do this) into the CIB stuff. @msyriac

ChangePrecision?

Given we deal with hundreds of millions of Websky halos, we default to Float32 rather than Float64. So perhaps ChangePrecision will be useful someday, per @xzackli in #36 (review)_

separate interpolator generation for model from source generation

at the moment get_interpolators runs every time generate_sources happens. this results in an inefficiency that is admittedly very minor, but if interpolator generation becomes expensive for whatever reason at some future point, for chunked runs it is likely more performant to generate interpolators once for the whole halo catalogue and then pass that to the per-chunk function each time.

thread safety

XGPaint until this point has been used on very large sky areas and a huge number of halos. Shared-memory calculations where multiple threads mutate one shared array has been ok, because the sources in each thread's chunk are super far away from each other on the sky.

Now that we're generating smaller patches, we should probably make a small workspace structure that holds a copy of the map for each thread.

Then we'll add up the final maps at the end. For large maps, it still makes sense not to make 32 copies of the full sky, so we should probably have an option to do what XGPaint currently does.

radio sources sorted at 100 GHz

We should sort them just once, at an important frequency (i.e. 100 GHz).

what exactly is wrong with websky CIB?

I'd like to collect some overplots of data and websky CIB predictions. I'll see if I can bring back the Planck auto spectra plots. That's one of the things that Websky does right (to my knowledge), and is one of the key constraints for this model.

My impression is that there is something wrong with the redshift evolution of flux in frequencies. How do we know about that? What are other data constraints?

Does this CIB model agree with the Shang halo model C_ell that Boris has?

remove dependencies

This has way too many dependencies.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

CIB conditional luminosities

• Poisson draw dn/dL(L|M, z) in xgpaint — can be provided by user or, in the case of the exisitng websky model, calculate dn/dL = dn/dmsub * dmsub / dL, where L = L_0 * Sigma(msub) and dn/dmsub is the subhalo mass function already included
• Plot the dn/dL(L|M, z) for the existing websky subhalo HOD model

randomisation performance

it would be good to figure out if calling rand for each satellite individually is really the best approach, or if pre-allocating however many random numbers are needed is better. of course the latter approach would increase memory requirements to some extent, so even if pre-allocated rands results in faster performance it'd probably need to be possible to turn that on/off.

better documentation of new observables

Merging websky-co into main comes with some new observables: LRGs and CO lines in broadband bandpasses. These need better documentation on two fronts:

• a Markdown tutorial in the docs, like what already exists for CIB and tSZ (per @xzackli in #36 (review))
• better docstrings? eg quasiTCO as in #36 (comment)

list comprehension bad (change LRG interpolator vector return)

not a major issue but find a way to rewrite this as a for loop with a pre-allocated Vector of LinearInterpolation objects ... ?
per @xzackli in #36 (comment)

Bug in the definition of Sigma_cen

It seems to me that the definition of sigma_cen is missing a square in model.shang_sigmaM https://github.com/xzackli/XGPaint.jl/blob/aee8f41fbf712153b8f9cd8f231fef05ef6ddbf7/src/cib.jl#L103

See eq. 23 of https://arxiv.org/abs/1109.1522 .Could you please confirm that ?

Also in
https://github.com/xzackli/XGPaint.jl/blob/aee8f41fbf712153b8f9cd8f231fef05ef6ddbf7/src/cib.jl#L108
it doesn't seem implemented the SED form adopted in eq.24 of https://arxiv.org/abs/1109.1522 . why ?

regression tests for randomised outputs

CO and Scarfy CIB stuff has log-normal scatter built in, but that shouldn't stop us from writing runtests. So at some point we should write end-to-end regression tests based on StableRNGs, per @xzackli in #36 (review)