827

Examining the Effect of the Map-Making Algorithm on Observed Power Asymmetry in WMAP Data

Peter E. Freeman, Christopher R. Genovese, Christopher J. Miller, Robert C. Nichol, and Larry Wasserman

Abstract:

We analyze first-year data of WMAP to determine the significance of asymmetry in summed power between arbitrarily defined opposite hemispheres. We perform this analysis on maps that we create ourselves from the time-ordered data, using software developed independently of the WMAP team. We find that over the multipole range $l$ = [2,64], the significance of asymmetry is $\sim$ 10$^{-4}$, a value insensitive to both frequency and power spectrum. We determine the smallest multipole ranges exhibiting significant asymmetry, and find twelve, including $l$ = [2,3] and [6,7], for which the significance $\rightarrow$ 0. Examination of the twelve ranges indicates both an improbable association between the direction of maximum significance and the ecliptic plane (significance $\sim$ 0.01), and that contours of least significance follow great circles inclined relative to the ecliptic at the largest scales. The great circle for $l$ = [2,3] passes over previously reported preferred axes and is insensitive to frequency, while the great circle for $l$ = [6,7] is aligned with the ecliptic poles. We examine how changing map-making parameters, e.g., foreground masking, affects asymmetry. Only one change appreciably reduces asymmetry: asymmetry at large scales ($l \leq$ 7) is rendered insignificant if the magnitude of the WMAP dipole vector (368.11 km s$^{-1}$) is increased by $\approx$ 1-3$\sigma$ ($\approx$ 2-6 km s$^{-1}$). While confirmation of this result requires the recalibration of the time-ordered data, such a systematic change would be consistent with observations of frequency-independent asymmetry. We conclude that the use of an incorrect dipole vector, in combination with a systematic or foreground process associated with the ecliptic, may help to explain the observed power asymmetry.

Here is the full PDF text for this technical report. It is 4766908 bytes long.