-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulate bandpass mismatch with PySM for numerous arrays #75
Comments
@keskitalo based on today's discussion I thought about an approach for simulating bandpass mismatch, do you think this would work? |
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? |
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.
Yes I think this also works, but it is more complicated, how do you properly estimate the derivatives? |
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. |
Precompute sum of components at delta frequenciesWith 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 |
@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? |
This depends on each individual fab. Do you want detector to detector on a given wafer or between wafers? The second is usually larger |
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. |
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) |
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. |
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:
Next level:
The text was updated successfully, but these errors were encountered: