WMAP5 data: foreground reduced I maps and their SYNFAST simulations

 Posts: 6
 Joined: February 25 2009
 Affiliation: University of Heidelberg
WMAP5 data: foreground reduced I maps and their SYNFAST sim
Hi,
I'm going to analyze largescale characteristics of the CMB and currently trying to get familiar with data evaluation and its simulation by SYNFAST.
I'm using the WMAP5 foreground reduced temperature maps per frequency band, available on LAMBDA (e.g. wmap_band_forered_iqumap_r9_5yr_V_v3.fits). Thereby, I observed something strange when comparing the map to Gaussian simulations. To get started, I wanted to compare the rms temperature fluctuations on large scales of real maps with their simulations.
First of all, I multiply a map (e.g. the V map) by the appropriate mask for temperature analysis (wmap_ext_temperature_analysis_mask_r9_5yr_v3.fits, also on LAMBDA) and degrade it to Healpix resolution 8 (via the Healpix fortran routine UD_GRADE). Now, the map is pixelized on a scale of about 7 degrees.
Then, I calculated the map's rms temperature fluctuation on this scale, just by averaging the square of the temperature fluctuations delta_T in each pixel over the whole map and taking the squareroot in the end.
This value is to be compared to Gaussian simulations, created by the Healpix facility SYNFAST based on the WMAP5 best fit Cl spectrum (e.g. computed by CAMB with the parameter file given by LAMBDA, see below). I expected the following: Since the bestfit Cls originate from the true WMAPmaps, my real rms temperature fluctuation should be (nearly) the same as the mean value of many Gaussian simulations running through the same masking and degrading procedure.
But that is not what I observe!
The mean value of the rms temperature fluctuations of a bunch of Gaussian simulations is about a factor of 1.4 too large.
I cannot find any explanation for this discrepancy. The instrument noise can be neglected on this large scale and could only correct into the wrong direction, I guess.
Do I understand something wrong or can anybody see a mistake?
Any hints are welcome!
Cheers,
Maik
If it helps you, here is the parameter fie for CAMB as downloaded from LAMBDA:
#########################################################
output_root = bestfit
get_scalar_cls = T
get_vector_cls = F
get_tensor_cls = F
COBE_normalize = F
CMB_outputscale = 7.425625e12
get_transfer = T
do_nonlinear = 0
l_max_scalar = 2000
k_eta_max_scalar = 4000
do_lensing = T
lensing_method = 1
w = 1
cs2_lam = 1
hubble = 0.724365E+02
use_physical = T
ombh2 = 0.226823E01
omch2 = 0.108085E+00
omnuh2 = 0
omk = 0
temp_cmb = 2.725
helium_fraction = 0.24
massless_neutrinos = 3.04
massive_neutrinos = 0
nu_mass_eigenstates = 1
nu_mass_degeneracies = 0
nu_mass_fractions = 1
transfer_high_precision = T
transfer_kmax = 2
transfer_k_per_logint = 0
transfer_num_redshifts = 1
transfer_interp_matterpower = T
transfer_power_var = 7
transfer_redshift(1) = 0
transfer_filename(1) = transfer_out.dat
transfer_matterpower(1) = matterpower.dat
reionization = T
re_use_optical_depth = T
re_optical_depth = 0.890432E01
re_delta_redshift = 0.5
re_ionization_frac = 1
pivot_scalar = 0.002
pivot_tensor = 0.002
initial_power_num = 1
scalar_spectral_index(1) = 0.960927E+00
scalar_nrun(1) = 0
scalar_amp(1) = 2.41147e09
RECFAST_fudge = 1.14
RECFAST_fudge_He = 0.86
RECFAST_Heswitch = 6
initial_condition = 1
scalar_output_file = scalCls.dat
lensed_output_file = lensedCls.dat
FITS_filename = scalCls.fits
accurate_polarization = T
accurate_reionization = T
accurate_BB = T
do_late_rad_truncation = F
do_tensor_neutrinos = T
feedback_level = 1
massive_nu_approx = 3
number_of_threads = 2
accuracy_boost = 2
l_accuracy_boost = 2
l_sample_boost = 2
####################################################
And here is one sample parameter file for SYNFAST:
#####################################################
simul_type = 1
nsmax = 512
nlmax = 1024
iseed = 70
beam_file = beam_V1.fits
infile = Cls.fits
outfile = ../temp/bestfit_512_10.fits
######################################################
(the beam shouldn't matter on the large scales I analyze, but nonethelesse, I've calculated the window functions by squaring the beam transfer function, available on LAMBDA)[tex][/tex]
I'm going to analyze largescale characteristics of the CMB and currently trying to get familiar with data evaluation and its simulation by SYNFAST.
I'm using the WMAP5 foreground reduced temperature maps per frequency band, available on LAMBDA (e.g. wmap_band_forered_iqumap_r9_5yr_V_v3.fits). Thereby, I observed something strange when comparing the map to Gaussian simulations. To get started, I wanted to compare the rms temperature fluctuations on large scales of real maps with their simulations.
First of all, I multiply a map (e.g. the V map) by the appropriate mask for temperature analysis (wmap_ext_temperature_analysis_mask_r9_5yr_v3.fits, also on LAMBDA) and degrade it to Healpix resolution 8 (via the Healpix fortran routine UD_GRADE). Now, the map is pixelized on a scale of about 7 degrees.
Then, I calculated the map's rms temperature fluctuation on this scale, just by averaging the square of the temperature fluctuations delta_T in each pixel over the whole map and taking the squareroot in the end.
This value is to be compared to Gaussian simulations, created by the Healpix facility SYNFAST based on the WMAP5 best fit Cl spectrum (e.g. computed by CAMB with the parameter file given by LAMBDA, see below). I expected the following: Since the bestfit Cls originate from the true WMAPmaps, my real rms temperature fluctuation should be (nearly) the same as the mean value of many Gaussian simulations running through the same masking and degrading procedure.
But that is not what I observe!
The mean value of the rms temperature fluctuations of a bunch of Gaussian simulations is about a factor of 1.4 too large.
I cannot find any explanation for this discrepancy. The instrument noise can be neglected on this large scale and could only correct into the wrong direction, I guess.
Do I understand something wrong or can anybody see a mistake?
Any hints are welcome!
Cheers,
Maik
If it helps you, here is the parameter fie for CAMB as downloaded from LAMBDA:
#########################################################
output_root = bestfit
get_scalar_cls = T
get_vector_cls = F
get_tensor_cls = F
COBE_normalize = F
CMB_outputscale = 7.425625e12
get_transfer = T
do_nonlinear = 0
l_max_scalar = 2000
k_eta_max_scalar = 4000
do_lensing = T
lensing_method = 1
w = 1
cs2_lam = 1
hubble = 0.724365E+02
use_physical = T
ombh2 = 0.226823E01
omch2 = 0.108085E+00
omnuh2 = 0
omk = 0
temp_cmb = 2.725
helium_fraction = 0.24
massless_neutrinos = 3.04
massive_neutrinos = 0
nu_mass_eigenstates = 1
nu_mass_degeneracies = 0
nu_mass_fractions = 1
transfer_high_precision = T
transfer_kmax = 2
transfer_k_per_logint = 0
transfer_num_redshifts = 1
transfer_interp_matterpower = T
transfer_power_var = 7
transfer_redshift(1) = 0
transfer_filename(1) = transfer_out.dat
transfer_matterpower(1) = matterpower.dat
reionization = T
re_use_optical_depth = T
re_optical_depth = 0.890432E01
re_delta_redshift = 0.5
re_ionization_frac = 1
pivot_scalar = 0.002
pivot_tensor = 0.002
initial_power_num = 1
scalar_spectral_index(1) = 0.960927E+00
scalar_nrun(1) = 0
scalar_amp(1) = 2.41147e09
RECFAST_fudge = 1.14
RECFAST_fudge_He = 0.86
RECFAST_Heswitch = 6
initial_condition = 1
scalar_output_file = scalCls.dat
lensed_output_file = lensedCls.dat
FITS_filename = scalCls.fits
accurate_polarization = T
accurate_reionization = T
accurate_BB = T
do_late_rad_truncation = F
do_tensor_neutrinos = T
feedback_level = 1
massive_nu_approx = 3
number_of_threads = 2
accuracy_boost = 2
l_accuracy_boost = 2
l_sample_boost = 2
####################################################
And here is one sample parameter file for SYNFAST:
#####################################################
simul_type = 1
nsmax = 512
nlmax = 1024
iseed = 70
beam_file = beam_V1.fits
infile = Cls.fits
outfile = ../temp/bestfit_512_10.fits
######################################################
(the beam shouldn't matter on the large scales I analyze, but nonethelesse, I've calculated the window functions by squaring the beam transfer function, available on LAMBDA)[tex][/tex]

 Posts: 3
 Joined: October 08 2007
 Affiliation: Cambridge IoA
WMAP5 data: foreground reduced I maps and their SYNFAST sim
It seems plausible that this is due to the lack of observed lowmultipole CMB power.
If I form C(0) \propto \sum_{L} (2L+1) C_L * B_L, where B_L is a 7 degree FWHM beam then I get a ratio of about 1.3 between the 5yr bestfit LCDM Cls and the ML estimated Cls. That you get 1.4 is probably because the power deficit is even more pronounced outside the sky cut.
A sanity check would be to do this again with the ILC map, the ML Cls, and no skycut. Then I hope you will find agreement!
Cheers,
Duncan.
If I form C(0) \propto \sum_{L} (2L+1) C_L * B_L, where B_L is a 7 degree FWHM beam then I get a ratio of about 1.3 between the 5yr bestfit LCDM Cls and the ML estimated Cls. That you get 1.4 is probably because the power deficit is even more pronounced outside the sky cut.
A sanity check would be to do this again with the ILC map, the ML Cls, and no skycut. Then I hope you will find agreement!
Cheers,
Duncan.

 Posts: 6
 Joined: February 25 2009
 Affiliation: University of Heidelberg
WMAP5 data: foreground reduced I maps and their SYNFAST sim
Thank you for your response! You're right, the lack of power in the low multipoles seems to be responsible. This is plausible, because mainly the low multipoles enter the analysis due to the window function on such large scales.
I was confused, because I always thought that such a large cold spot as found by Vielva et al.is not to be expected in LCDM. But if significant power lacks on large scales, we should expect even more of this kind, shouldn't we?
Maik
I was confused, because I always thought that such a large cold spot as found by Vielva et al.is not to be expected in LCDM. But if significant power lacks on large scales, we should expect even more of this kind, shouldn't we?
Maik
WMAP5 data: foreground reduced I maps and their SYNFAST sim
Hi Maik,
I guess an important thing you missed is the noise. Well, the S/N is high on large scales but the instrumental noise is inhomogeneous due to WMAP scanning strategy. So conservatively, you should also simulate the noise realizations with WMAP instrumental properties (white noise, mainly), adding to your Gaussian temperature maps. It is easy to find how to simulate WMAP noise realizations from literatures.
The monopole and dipole should also be the problem. You mentioned you had applied the mask both on the WMAP and simulated maps, however, it seems you haven't removed the monopole and dipole outside the mask. Even for a full sky map with zero monopole and dipole, after applying the mask, the [tex]\ell[/tex]modes of this map will be coupled, there are "residual" monopole and dipole on it, and you must fit and remove them. I hope the IDL routine or Fortran subroutine "remove_dipole" will help you. Be careful, before removal, you should set the masked region as HEALPix sentinel value (1.6375e30) to fit and remove moments just outside the mask (you can check HEALPix manual or have a look at the source code).
What do you mean by "I've calculated the window functions by squaring the beam transfer function"? I don't understand.
Cheers
Zhen
I guess an important thing you missed is the noise. Well, the S/N is high on large scales but the instrumental noise is inhomogeneous due to WMAP scanning strategy. So conservatively, you should also simulate the noise realizations with WMAP instrumental properties (white noise, mainly), adding to your Gaussian temperature maps. It is easy to find how to simulate WMAP noise realizations from literatures.
The monopole and dipole should also be the problem. You mentioned you had applied the mask both on the WMAP and simulated maps, however, it seems you haven't removed the monopole and dipole outside the mask. Even for a full sky map with zero monopole and dipole, after applying the mask, the [tex]\ell[/tex]modes of this map will be coupled, there are "residual" monopole and dipole on it, and you must fit and remove them. I hope the IDL routine or Fortran subroutine "remove_dipole" will help you. Be careful, before removal, you should set the masked region as HEALPix sentinel value (1.6375e30) to fit and remove moments just outside the mask (you can check HEALPix manual or have a look at the source code).
What do you mean by "I've calculated the window functions by squaring the beam transfer function"? I don't understand.
Cheers
Zhen
Re: WMAP5 data: foreground reduced I maps and their SYNFAST
In my opinion, if significant power lacks on large scales, i.e. the temperature variance is low on large scale, which means there is a lack of fluctuation on large scale temperature field. Thus the probability to find a big cold (or hot) region is low.Maik Weber wrote: But if significant power lacks on large scales, we should expect even more of this kind, shouldn't we?

 Posts: 6
 Joined: February 25 2009
 Affiliation: University of Heidelberg
WMAP5 data: foreground reduced I maps and their SYNFAST sim
Hi Zhen,
thank you for your response!
I will try to simulate noise and remove monopole and dipole after masking. I have thought about both effects before, but always expected them to be negligible in my analysis. But you're right that I should check it!
Concerning the beam functions:
Synfast asks for a window function before simulating a sky map. On LAMBDA you can find beam transfer functions for each differencing assembly (e.g. http://lambda.gsfc.nasa.gov/data/map/dr ... 5yr_v3.txt) and the header says: 'The window function is the square of the
beam transfer function.'
Therefore, I squared the values in order to get the right function for synfast. I hope this was correct? Anyway, I couldn't notice much difference to using the default gaussian beam.
Cheers,
Maik
thank you for your response!
I will try to simulate noise and remove monopole and dipole after masking. I have thought about both effects before, but always expected them to be negligible in my analysis. But you're right that I should check it!
Concerning the beam functions:
Synfast asks for a window function before simulating a sky map. On LAMBDA you can find beam transfer functions for each differencing assembly (e.g. http://lambda.gsfc.nasa.gov/data/map/dr ... 5yr_v3.txt) and the header says: 'The window function is the square of the
beam transfer function.'
Therefore, I squared the values in order to get the right function for synfast. I hope this was correct? Anyway, I couldn't notice much difference to using the default gaussian beam.
Cheers,
Maik

 Posts: 6
 Joined: February 25 2009
 Affiliation: University of Heidelberg
Re: WMAP5 data: foreground reduced I maps and their SYNFAST
Yes, that is my opinion, too. My previous post was perhaps a little bit confusing. When compared to LCDM the WMAPdata misses power on largescales. Nevertheless, there is this large Vielva cold spot, which is sometimes quoted as a challenge for LCDM. But if LCDM predicts even higher power on large scales and thereby more of these big hot/cold regions, I would rather say, that the Vielva cold spot is closer to LCDM than the rest of the largescale CMB.Zhen Hou wrote: In my opinion, if significant power lacks on large scales, i.e. the temperature variance is low on large scale, which means there is a lack of fluctuation on large scale temperature field. Thus the probability to find a big cold (or hot) region is low.
I guess, most people investigate gaussianity of the temperature field and therefore are not interested in the absolute magnitude. When they analyze a somehow normalized temperature field the cold spot must appear as a striking deviation from gaussianity.
Maik

 Posts: 6
 Joined: February 25 2009
 Affiliation: University of Heidelberg
WMAP5 data: foreground reduced I maps and their SYNFAST sim
Finally, I've added white noise to the Gaussian simulations and also removed the monopole and the dipole of each map outside the masked region. In order to check whether the lack of power of the low multipoles may be responsible, I've also replaced the bestfit Cl's by the actually measured unbinned WMAP5Cl's (available on LAMBDA).
But the discrepancy survived!
Still, the simulated maps' rms temperature fluctuation is significantly (2 sigma) higher. Although this is a little bit better than before, compared to these Gaussian simulations the distribution of big hot and cold areas of the real CMB would be really challenging...
Is this a physical effect or still an error in the procedure?
Cheers
Maik
But the discrepancy survived!
Still, the simulated maps' rms temperature fluctuation is significantly (2 sigma) higher. Although this is a little bit better than before, compared to these Gaussian simulations the distribution of big hot and cold areas of the real CMB would be really challenging...
Is this a physical effect or still an error in the procedure?
Cheers
Maik

 Posts: 3
 Joined: October 08 2007
 Affiliation: Cambridge IoA
WMAP5 data: foreground reduced I maps and their SYNFAST sim
What do you get if you use the ILC map and no mask?

 Posts: 6
 Joined: February 25 2009
 Affiliation: University of Heidelberg
WMAP5 data: foreground reduced I maps and their SYNFAST sim
Now, that is quite interesting:
The fullsky ILC map is consistent with Gaussian simulations build on the measured Cl spectrum, whereas the skycut ILC map is consistent with the other skycut maps (Vband for example). None of them is consistent with LCDM, which needs more correlation.
As far as I understand these observations, the WMAP5 data lacks power outside the galaxy and the fullsky ILC 'balances' this mismatch by putting much power into the galaxy region, with which I do not feel too comfortable...
In any case, in comparison to LCDM there is definitely not enough power on large scales. While this discrepancy doesn't strike strongly in harmonic space, it is much more visible in pixel space (e.g. the distribution of big hot/cold areas or the rms temperature fluctuation in a window).
See also 0808.3767v1. They seem to have observed the same effects with different methods.
But of course, the above statements are only my first impressions and are not based on a full statistical analysis including cosmic variance and other sources of error.
Cheers,
Maik
The fullsky ILC map is consistent with Gaussian simulations build on the measured Cl spectrum, whereas the skycut ILC map is consistent with the other skycut maps (Vband for example). None of them is consistent with LCDM, which needs more correlation.
As far as I understand these observations, the WMAP5 data lacks power outside the galaxy and the fullsky ILC 'balances' this mismatch by putting much power into the galaxy region, with which I do not feel too comfortable...
In any case, in comparison to LCDM there is definitely not enough power on large scales. While this discrepancy doesn't strike strongly in harmonic space, it is much more visible in pixel space (e.g. the distribution of big hot/cold areas or the rms temperature fluctuation in a window).
See also 0808.3767v1. They seem to have observed the same effects with different methods.
But of course, the above statements are only my first impressions and are not based on a full statistical analysis including cosmic variance and other sources of error.
Cheers,
Maik