What's New on LAMBDA: 12-Jul-06
http://lambda.gsfc.nasa.gov/outreach/whatsnew.cfm
Augmented Cosmological Parameter Table
The cosmological parameter table has been augmented with 3 additional models: non-flat CDM ("ocdm"), non-flat CDM with quintessence ("ocdm+wpert"), and flat CDM with a running spectral index and tensors ("lcdm+run+tens").
(This is an automated web monitor message)
LAMBDA update: 12-Jul-06
-
Aseem Paranjape
- Posts: 8
- Joined: December 23 2005
- Affiliation: IUCAA, Pune, India
LAMBDA update: 12-Jul-06
There seems to be something wrong with the numbers in the 'ocdm' parameters using WMAP. The most obvious thing is that [tex]\Omega_m = 0.77[/tex] and [tex]\Omega_\Lambda = 0.75[/tex] don't add up to [tex]\Omega_{tot} = 1.15[/tex]. Also, with [tex]h=0.45[/tex] one doesn't get [tex]\Omega_mh^2 = 0.128[/tex].
I haven't looked for other errors, and also haven't looked carefully at any of the other parameter tables.
Can someone check/clarify this?
I haven't looked for other errors, and also haven't looked carefully at any of the other parameter tables.
Can someone check/clarify this?
LAMBDA update: 12-Jul-06
I checked some of the other parameter tables and they look OK to me. The "ocdm" chain I think was done more recently than the others, and maybe something caused a glitch in the automatic table generation. It should get fixed sometime in the next few days.
But I just looked at the chain itself a bit, and my guess is that the problem is that \Omega_m and \Omega_\Lambda are both poorly constrained, and the value quoted for \Omega_\Lambda appears to be an upper limit. When I take the average \Omega_\Lambda for the chain, I get 0.38, which together with the average \Omega_m matches the \Omega_k given. But the constraints on \Omega_m and \Omega_\Lambda from WMAP alone are just very poor (though the constraint on their sum \Omega_{tot} isn't quite as horrible).
The combination \Omega_m h^2 actually isn't bad at all, so I think those numbers are probably fine. It doesn't quite match the given \Omega_m and H_0, but the constraints on those two individually are so bad that it's well within the error.
But I just looked at the chain itself a bit, and my guess is that the problem is that \Omega_m and \Omega_\Lambda are both poorly constrained, and the value quoted for \Omega_\Lambda appears to be an upper limit. When I take the average \Omega_\Lambda for the chain, I get 0.38, which together with the average \Omega_m matches the \Omega_k given. But the constraints on \Omega_m and \Omega_\Lambda from WMAP alone are just very poor (though the constraint on their sum \Omega_{tot} isn't quite as horrible).
The combination \Omega_m h^2 actually isn't bad at all, so I think those numbers are probably fine. It doesn't quite match the given \Omega_m and H_0, but the constraints on those two individually are so bad that it's well within the error.
LAMBDA update: 12-Jul-06
I heard back, and the "official" word is that the \Omega_\Lambda number is an upper limit and the file will be fixed to denote it as such.
As for the \Omega_m, H_0, and \Omega_m h^2 not agreeing, it turns out that it's important to remember that these are all mean values over some likelihood distribution. In particular, the mean of H_0 is not equal to the sqrt of the mean of H_0^2 even for a normal distribution, unless the standard deviation is small compared to the mean. For the "ocdm" chain neither of these conditions is true. So the quoted numbers are actually all correct.
As for the \Omega_m, H_0, and \Omega_m h^2 not agreeing, it turns out that it's important to remember that these are all mean values over some likelihood distribution. In particular, the mean of H_0 is not equal to the sqrt of the mean of H_0^2 even for a normal distribution, unless the standard deviation is small compared to the mean. For the "ocdm" chain neither of these conditions is true. So the quoted numbers are actually all correct.