The discussion revolves around potential inconsistencies in Jorrie’s Cosmo-Calculator, particularly when comparing results from the calculator based on the ΛCDM model with those from Gnedin’s and Wright’s calculators. Participants explore the nature of these discrepancies, possible glitches, and the underlying calculations involved.
Participants do not reach a consensus on the existence of a glitch in Jorrie’s calculator, as multiple competing views and hypotheses about the source of discrepancies remain. There is ongoing exploration of potential fixes and improvements, but no definitive agreement on the nature of the problem.
Limitations include unresolved mathematical steps related to the numerical integration and the specific implementation details of the calculator's algorithms. The discussion also highlights the dependence on the definitions and parameters used in the calculations.
pbuk said:
Not exactly, there is a much more sophisticated treatment of dark energy. You can see the code (in R) if you go to https://cosmocalc.icrar.org/ and click the "R code" tab.JimJCW said:
pbuk said:
Rather than reverse engineer output I'd rather look at the implementations themselves. For instance the constants used in Jorrie's original model include these:JimJCW said:
// https://github.com/light-cone-calc/light-cone-calc/blob/main/src/model.ts
const physicalConstants = {
rhoConst: 1.7885e9, // 3 / (8 pi G)
secInGy: 3.1536e16, // s / Gyr
tempNow: 2.725, // CMB temperature now
convertToGyr: 1 / 978, // Convert km/s/Mpc -> Gyr^-1
};// https://github.com/joshkempner/Cosmic.NET/blob/main/Cosmic.NET/cosmo/Cosmo.cs
private const double c = 2.99792458e5; // speed of light
private const double G = 6.67259e-8; // gravitational constant
private const double KmPerMpc = 3.08567758e19;
private const double TropicalYear = 3.1556926e7; // in seconds// s_eq: 1 + 3370, // Stretch when OmegaM=OmegaR
...
//@TODO check this - should it be s_eq + 1 as the original, or as below
// from Ibix?
// const OmegaM = ((Omega - OmegaL) * s_eq) / (s_eq + 1); // Energy density of matter
// const OmegaR = OmegaM / s_eq; // Energy density of radiation
const OmegaM = ((Omega - OmegaL) * (s_eq + 1)) / (s_eq + 2); // Energy density of matterYes of course.Jorrie said:
I used yours, but it's a quick fix.Jorrie said:
Tiny but important: this was the remaining part of the problem causing the offset at z = 0.Jorrie said:
z: 0
Dnow: 3.552713678800501e-15
Dthen: 3.552713678800501e-15
Vnow: 2.460744627831758e-16
Vthen: 2.4607446278317573e-16Great stuff! I will link https://light-cone-calc.github.io/ in my signature and you can do the same, if you so wish.pbuk said:
Thanks for that, it is an unintended side effect of fixing the range so it includes z = 0 instead of z = 1e-6 for instance. I'll fix the fix.JimJCW said:
My first suspicion is the values of certain constants, particularly the conversion factor from ## km\\s^{-1}\\Mpsc^{-1} ## to ## Gyr^{-1} ## which is a simple ## \frac 1 {978} ## in LightCone8 instead of something like ## \frac{365.2421897 \times 86400 \times 1000000 \pi}{96939420213600000} ##.JimJCW said:
| z | OmegaM | OmegaL | OmegaR | OmegaT |
LightCone8 | 0 | 0.309000000 | 6.910000000 | 0.00009169139 | 1.000091691 |
From Equations | 0 | 0.308908363 | 6.91 | 0.000091637 | 1 |
Thanks, I think this is related to https://github.com/light-cone-calc/light-cone-calc/issues/6JimJCW said:
Jorrie said:
I think the error is in the UI: we should have ## \Omega_{m,0} = \Omega - \Omega_{\Lambda,0} = 1 - 0.691 = 0.309 ##.JimJCW said:
pbuk said:
I have checked the UI calculation and it seems to be right if radiation density is included, as it should.pbuk said:
Jorrie said:
rholNow = rhocritNow * Ol;
rhol = rholNow;
rhomNow = rhoNow - rhol;
rhom = rhomNow *s*s*s;
rhorNow = rhomNow/s_eq;
rhor = rhorNow *s*s*s*s;Yes, at any time, ##\rho_{0} = \rho_{r,0} + \rho_{m,0} + \rho_{\Lambda,0}##. In the case ##\Omega = 1##, this is subject to the constraint$$\rho_{0} = \rho_\mathrm{critical} = \frac{3 H_0^2 }{8 \pi G},$$pbuk said:
Yes, the same differences occur in Lightcone7, but it is calculated differently than the value in the UI. I will check that part and make it compatible, because I still feel that the value in the UI is correct.pbuk said:
Minor corrections (red) in Calculation.js required to improve the issue:Jorrie said:
George, how do the equations change in the case where ##\Omega \ne 1##?George Jones said:
I am not sure which equations you mean. ##\Omega = \Omega_r + \Omega_m + \Omega_\Lambda## is always true, as is ##\Omega + \Omega_k = 1##. If ##\Omega = 1##, then ##\Omega_k =0##, but if f ##\Omega \neq 1##, then ##\Omega_k \neq 0##.Jorrie said:
I suspect @Jorrie is suffering from the same problem as I am with the confusing terminology. I am working on increasing consistency for my rewrite:George Jones said:
omegaM - density of mass as a fraction of the critical density.omegaLambda - density of the cosmological constant as a fraction of the critical density.omegaRad - density of radiation as a fraction of the critical density.omega - total density of [stuff] as a fraction of the critical density ## \Omega = \Omega_{m} + \Omega_{\Lambda} + \Omega_{rad} ##.omegaK - Do we bother with this?omegaM0 - density of mass now as a fraction of the critical density now.omegaLambda0 - density of the cosmological constant now as a fraction of the critical density now.omegaRad0 - density of radiation now as a fraction of the critical density now.omega0 - total density of [stuff] now as a fraction of the critical density now ## \Omega_{0} = \Omega_{[m,0]} + \Omega_{[\Lambda,0]} + \Omega_{[rad,0]} ##.omegaK0 - curvature now as a fraction of the critical density now (is this actually constant in all models?) ## \Omega_{[K,0]} = 1 - \Omega_{0} ##.Common practice in cosmology is to write "something" in terms of redshift ##z##, i.e., to substitute ##s = 1 + z## for every ##s##. Common cosmological notation is ## [something] = \frac{H\left(z\right)^2}{H_0^2} =: E\left(z\right)^2##. I am not sure why.pbuk said: