Simulate bandpass mismatch with PySM for numerous arrays

[zonca]

Current sky models at high resolution are very expensive to run, especially memory-wise.

A complete sky model with CMB, foregrounds and extragalactic can have 8-9 components, each needs to load a number of high resolution maps, generally 2 or 3, but sometimes 5 or 6.

Running PySM on the fly for time domain simulations is very expensive. Some pre-computation is most probably needed.
The simplest model would be to only simulate the impact of shifting the center of the bandpass, keeping bandwidth and shape the same for all detectors.

My proposal for this is:

• Choose a representative band shape, simplest is top-hat, but it would be better if we have something more realistic (i.e. lower towards the edges)
• Precompute with PySM complete sky maps densely around the center frequency. E.g. we are simulating 40GHz, the tolerance of center frequency is +-1 GHz, we create 1 PySM map which includes all components for 39GHz, 39.2, 39.4...40.8 41GHz, so ~11 maps.
• the time domain simulation tool (TOAST) doesn't run PySM, it loads the 11 maps, then for each detector draws a center frequency 39-40GHz and interpolates linearly the 2 closest maps

Next level:

• Also modulate bandwidth, based on center frequency - the PySM maps have a 30% bandwidth, so the 39GHz channel has smaller bandwidth
• Also modulate bandwidth, independently - we precompute PySM for 5 points in frequency and 4 different bandwidths, produce 20 maps

[zonca]

@keskitalo based on today's discussion I thought about an approach for simulating bandpass mismatch, do you think this would work?

[keskitalo]

Different spectral indices imply different shifts in central frequency for the same bandpass. I don't see how this model would work for more than one foreground component at the time. And not even then if the component has varying spectral index across the sky.

In the NPIPE analysis we took each foreground component and evaluated the component and its frequency derivative at the nominal center frequency. Then we constructed the bandpassed sky as a sum of the center frequency maps and their derivatives, allowing for different prefactors for each foreground derivative. Perhaps something like this would work?

[zonca]

Different spectral indices imply different shifts in central frequency for the same bandpass. I don't see how this model would work for more than one foreground component at the time. And not even then if the component has varying spectral index across the sky.

I don't follow you here. I am not simulating the sky at the center frequency, I am integrating the whole bandpass just shifted by the center frequency shift. So I capture both the different spectral indices of the components and also if a component has varying spectral index across the sky.

In the NPIPE analysis we took each foreground component and evaluated the component and its frequency derivative at the nominal center frequency. Then we constructed the bandpassed sky as a sum of the center frequency maps and their derivatives, allowing for different prefactors for each foreground derivative. Perhaps something like this would work?

Yes I think this also works, but it is more complicated, how do you properly estimate the derivatives?

[keskitalo]

I must have misunderstood. Yes, if you are convolving the sky model with the shifted bandpasses, that obviously works. The only trouble is that it locks you into a particular shape and mismatch of bandpass.

The NPIPE formalism can accommodate various bandpass shapes. Different shapes map to different prefactors on the derivatives. As for evaluating the derivatives themselves, that just requires two evaluations of the sky model near the nominal center frequency.

[zonca]

Precompute sum of components at delta frequencies

With similar memory usage of the 2 approaches above, we could also precompute the sky emission with all the components summed at 10 or 20 points in frequency (delta-frequency), possibly distributed more densely in the center of the band and more sparsely at the sides. Then integrate the bandpasses with trapz or something similar for each channel.
Is discretizing bandpass response in 10 or 20 points enough to capture its impact?
I think in any case it would be useful to have some expected bandpasses and some details about their variability across an array, so we could do some tests of these methods.

[zonca]

@smsimon in https://github.com/simonsobs/instrument_model/tree/master/instrument_hardware/modeled_bandpasses we have some expected average bandpasses. Do we have any idea on how do bandpasses vary from detector to detector?

[smsimon]

This depends on each individual fab. Do you want detector to detector on a given wafer or between wafers? The second is usually larger

[zonca]

thanks @smsimon it would be nice to have both, even if they are approximate, they would still help understand how to better do the integration.

[smsimon]

I think we can just assume a ~2% uncertainty for now (there's also systematic effects in measuring the bands, but those are more difficult to parameterize)

[jdborrill]

Assuming that the band doesn't change over the course of the mission, this cost is massively subdominant to the time-domain processing unless we cut the timestream into many small, independent, jobs.

[giuspugl]

Hi all,
i've worked on a module to simulate realistic bandpasses with several levels of complexity.
You can sample from a top-hat , a top-hat with two apodization profile (e.g. cosine and exponential) and from a Chebyshev polynomial .

Once the sampler of your bandpass is constructed it can easily apply to multiple detector arrays for a given freq. channel , e.g. :

please lemme know if it can be of any use!