Sky model for LAT+SAT TOD simulation

[zonca]

On the wiki at http://simonsobservatory.wikidot.com/mss-0001 the TOD2MAPS team is defining the details of the first TOD simulation using TOAST.

I will add support in TOAST for so_pysm_models, now we need to decide which models should go in. Consider that the plan is that everything will be summed together in the timelines.

I suggest we run at 4096 for LAT and 512 for SAT, using the fixed-spectral-index high-resolution sky models prepared by @NicolettaK for the https://github.com/simonsobs/map_based_simulations/tree/master/201903_highres_foregrounds simulation, i.e.:

• dust
• synchtrotron
• freefree
• ame

On top of that also the first CMB realization from the previous simulation run (https://github.com/simonsobs/map_based_simulations/tree/master/201901_gaussian_fg_lensed_cmb_realistic_noise) i.e. lensed CMB with no primordial B-modes. Is this ok or we want primordial B-modes? if so, who will produce a fiducial input spectrum/map?

Also, we just finalized the integration of the extragalactic components (CIB / kSZ / tSZ), see the documentation, I'll be running a map based simulation soon. Should we add those as well?

[NicolettaK]

@zonca, good to me. For primordial B-modes I think @damonge and Josquin should decide whether they want r=0 or not.

[damonge]

@zonca no primordial B-modes is fine for this first run

[damonge]

From our conversation on slack: The ideal scenario for BB would be O(100) simulations with different noise and CMB seeds. Of these, O(80) of them would have r=0, with r=0.01 for the remaining O(20). The parameters used to generate the corresponding power spectra should be consistent (other than r). If the simulations won't be provided with the different components separated from each other, it'd be best if our simulations had a lensing B-mode amplitude of A_lens~0.5.

[zonca]

sorry @damonge @NicolettaK , this is actually a single-realization simulation.

So @damonge, for a single realization, do you prefer r=0 or r>0?

I would prefer not to add the extra-galactic components to simplify the simulations. Unless people request them.

[damonge]

r=0 is better in that case, I think

[msyriac]

We should definitely have a lensed CMB map as input (with the corresponding lensed map and kappa map saved). I don't have strong feelings on including tSZ, CIB and kSZ, generally leaning towards including them. @jcolinhill @ajvanengelen @marcelo-alvarez thoughts?

[jcolinhill]

what's the reason not to include tSZ/CIB/kSZ?

[msyriac]

One reason not to include them would be because only 1 sim is being produced for this run -- with the primary motivation (I think, correct me if I'm wrong) being a demonstration that the instrument/atmosphere can be simulated well. We would then want, for example, lensing biases from extragalactic foregrounds not to get in the way of our assessment of what the noise is doing in our pipelines. But the same argument can be made for Galactic foregrounds.

[ajvanengelen]

Right, I would argue that if Galactic emission is being included in a sim that is designed for a given application, why not include extra-Galactic emission as well.

Alex

On Apr 10, 2019, at 4:22 PM, Mathew S. Madhavacheril notifications@github.com wrote:

One reason not to include them would be because only 1 sim is being produced for this run -- with the primary motivation (I think, correct me if I'm wrong) being a demonstration that the instrument/atmosphere can be simulated well. We would then want, for example, lensing biases from extragalactic foregrounds not to get in the way of our assessment of what the noise is doing in our pipelines. But the same argument can be made for Galactic foregrounds.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simonsobs/so_pysm_models/issues/32#issuecomment-481847339, or mute the thread https://github.com/notifications/unsubscribe-auth/APAXHDguOwEOBvUlgmGNI74M2-9oI_cwks5vfkf1gaJpZM4cjlME.

[zonca]

the reason not to include is to simplify the simulation, but if people agree that it is useful, we can add it. @damonge do you have any preference about including or not tSZ/CIB/kSZ?

We should have a CMB realization lensed by the same matter distributed used in websky, right? Who takes charge of producing that?

[marcelo-alvarez]

To agree and expand on what's already been said, I think it depends on the goal. If it's to test the interfacing of TOAST with external sky models as currently implemented via so_pysm_models, then it should include Galactic, extragalactic, and Gaussian lensed primary CMB. If the goal is testing only the effects being simulated (instrument, scan strategy, atmosphere), then just the lensed primary CMB as input would probably be sufficient. Beyond that, no obvious argument comes to mind for one component over another in terms of either computational complexity or scientific benefit.

[damonge]

Sorry for the delay, I missed this one. I have zero preference with regards to tSZ etc. for the SAT (I doubt we'll look at temperature too much) Without my SAT hat on, I would have thought that adding these would be an epsilon of work compared with all the other stuff that goes into this sim, but I may be wrong.

[zonca]

@damonge it is more maps we have to keep in memory while we are generating the timelines for the detectors so it increases the memory footprint for the simulations, mostly for LAT which is at Nside 4096.

ok, so the plan is:

• high-resolution dust, synchrotron, free-free, ame with spatially-constant spectral index
• tSZ/CIB/kSZ from websky
• CMB with r=0 lensed with potential from websky

On Wednesday I'll write this on the wiki, please provide any other feedback before then.

@marcelo-alvarez @ajvanengelen can you take care of providing the CMB a_{lm}?

[damonge]

Ok I see. As I said, if it's problematic we (SAT) are perfectly fine without them. The plan sounds good otherwise.

[zonca]

@marcelo-alvarez @ajvanengelen do you have already the CMB a_{lm} mentioned here? do you have some documentation about them?

[marcelo-alvarez]

@ajvanengelen can correct me if I'm wrong and/or give additional details about what went into the CMB transfer function, but I believe they are fits files in standard alm format, located at /global/cscratch1/sd/engelen/webskylensing/data/unlensed_alm.fits /global/cscratch1/sd/engelen/webskylensing/data/lensed_alm.fits with cosmological parameters [r, omegab, omegam, h, ns, sigma8 = 0, 0.049, 0.31, 0.68, 0.965, 0.81]

[keskitalo]

I really think the CMB component in the simulation should include the solar system dipole. It often gets neglected because it is easy to remove but for the LAT it will source a significant amount of T->P leakage even in the absence of atmosphere.

We could simulate the dipole internally in TOAST but that is a costly calculation to do for every detector. It would be much more efficient to have it included in the CMB sky. Once the pipelines mature enough to include time-dependent orbital dipole simulation and removal, we'll have to perform the calculation in time domain.

[msyriac]

I support having the dipole in the CMB lensed alms. Does this just correspond to having some non-zero values in the alms for ell=1? What values should this be? A related issue is whether we should include aberration and modulation. @ajvanengelen what do you think?

[zonca]

@NicolettaK at the time we chose the SO_?0 fixed-spectral-index models because we were still debugging the SO_?1 models, do you think it would be better to switch to the variable-spectral-index models?

[zonca]

ok I implemented the dipole, using HFI solar dipole 2018 and finalized the rest of the sky model as discussed above (SO_?0 models). For the details see the README in (currently still finalizing it): https://github.com/simonsobs/map_based_simulations/pull/20