I A glitch in Jorrie’s Cosmo-Calculator?

  • Thread starter Thread starter JimJCW
  • Start date Start date
Click For Summary
Jorrie’s Cosmo-Calculator is experiencing persistent inconsistencies in results for Dnow and Dthen compared to Gnedin’s and Wright’s calculators, particularly at low redshift values. Users speculate there may be a glitch, possibly linked to numerical integration methods used in the calculator. Adjustments to the integration parameters have shown some reduction in error but not a complete fix, indicating deeper issues in the implementation. The calculator was originally designed as an educational tool, which may explain some of its limitations. Ongoing investigations are needed to address these discrepancies and improve accuracy.
  • #91
pbuk said:
It's already rewritten, now working here: https://light-cone-calc.github.io. There's not much point testing it against the ICRAR calculator though as that uses a more sophisticated model.

Great! I can make more comparisons.

Please explain what you mean by “. . . the ICRAR calculator . . . uses a more sophisticated model”. Doesn’t it calculate the same Dnow?
 
Space news on Phys.org
  • #92
JimJCW said:
Please explain what you mean by “. . . the ICRAR calculator . . . uses a more sophisticated model”. Doesn’t it calculate the same Dnow?
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.
 
  • #93
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.

How about comparing the cosmic model with your new version (setting ΩR = 0)? Similar discrepancy exists.
 
  • #94
JimJCW said:
How about comparing the cosmic model with your new version (setting ΩR = 0)? Similar discrepancy exists.
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:
JavaScript:
// 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
};

whereas cosmic uses these

C++:
// 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

Also, as noted in the code, I'm not sure about the calculation of ## \Omega_m ##
JavaScript:
//  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 matter

A better place to discuss this is probably https://github.com/light-cone-calc/light-cone-calc/issues - in fact I've already noted the last point here https://github.com/light-cone-calc/light-cone-calc/issues/6.
 
  • #95
Pbuk, Jim and Ibix, thanks for your great work!
We have a local 4-day weekend starting tomorrow, so I will take a look good at your Lightcone8 version and also at the issue that you raised on Github and discuss it there.
 
  • Like
Likes berkeman and pbuk
  • #96
Yes, There is an error in my old Legacy js code, line 356
Ibix is correct, i.e.
// const OmegaM = ((Omega - OmegaL) * s_eq) / (s_eq + 1); // Energy density of matter

Tiny, tiny influence, considering the uncertainty on the z_eq value.

@pbuk, which one did you use in Lightcone8?
 
  • #97
Jorrie said:
Ibix is correct, i.e.
// const OmegaM = ((Omega - OmegaL) * s_eq) / (s_eq + 1); // Energy density of matter

Tiny, tiny influence, considering the uncertainty on the z_eq value.
Yes of course.

Jorrie said:
@pbuk, which one did you use in Lightcone8?
I used yours, but it's a quick fix.
 
  • #98
Jorrie said:
Tiny, tiny influence, considering the uncertainty on the z_eq value.
Tiny but important: this was the remaining part of the problem causing the offset at z = 0.

Code:
z: 0
Dnow: 3.552713678800501e-15
Dthen: 3.552713678800501e-15
Vnow: 2.460744627831758e-16
Vthen: 2.4607446278317573e-16
These values should all be 0 of course. Now fixed.
 
  • #99
pbuk said:
Code:
z: 0
Dnow: 3.552713678800501e-15
Dthen: 3.552713678800501e-15
Vnow: 2.460744627831758e-16
Vthen: 2.4607446278317573e-16
These values should all be 0 of course. Now fixed.
Great stuff! I will link https://light-cone-calc.github.io/ in my signature and you can do the same, if you so wish.
Maybe do a last edit to take some credit for the improvement?
 
  • #100
Hi @Jorrie, @pbuk,

When trying LightCone8, I noticed that if zlower = 0, a duplicated line is printed at z = 0. For example:

1655545085892.png
 
  • #101
JimJCW said:
Hi @Jorrie, @pbuk,

When trying LightCone8, I noticed that if zlower = 0, a duplicated line is printed at z = 0.
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.
 
  • #102
Hi @Jorrie, @pbuk,

Let’s review the current situation of Jorrie’s calculator. First, LightCone8 updated by @pbuk has eliminated the glitch discussed in this thread (see Post #1):

1655861803812.png


ICRAR is an online calculator that includes ΩR,0 as an input parameter, just like LightCone8 (zeq = 3370). A comparison of the calculated Dnow’s using the two models is shown below:

1655861880350.png


The two results are almost indistinguishable. However, when their difference is plotted against z, the result shows,

1655861932658.png


The fact that ‘ICRAR - LightCone8’ is not a horizontal line near y = 0 suggests that there exists discrepancy between the two calculators. To look into this further, we note that ICRAR (ΩR=0), LightCone8 (ΩR=0), and cosmic (no ΩR) should give the same results, but they don’t:

1655862011899.png


The figure suggests that when ΩR=0, ICRAR and cosmic are consistent with each other, but not with LightCone8. The source of this discrepancy is unknown. It would be nice, though, to be able to identify it.

To summarize:

LightCone8 has removed the glitch discussed in this thread. However, it is noticed that there exist discrepancies between LightCone8 and some other online calculators, such as ICRAR and cosmic.​
 
  • #103
JimJCW said:
The figure suggests that when ΩR=0, ICRAR and cosmic are consistent with each other, but not with LightCone8. The source of this discrepancy is unknown. It would be nice, though, to be able to identify it.
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} ##.

I've raised an issue and will look at it: https://github.com/light-cone-calc/light-cone-calc/issues/11
 
  • #104
I have commented on the Github issues page.
 
  • #105
Hi @Jorrie and @pbuk,

I noticed some discrepancies in results from LightCone8. Let’s use the following input values:

1656585579240.png


Equations in Tutorial, part III,

Ωm = (Ω - ΩΛ) Seq / (1 + Seq), where Seq = zeq + 1​
ΩR = Ωm / Seq

give,

Ωm = 0.308908363
ΩR = 0.000091637

These numbers are compared with output of LightCone8 below:

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​

Note that under Conversions in the output, LightCone8 gives,

1656585842082.png


Conclusion: The values of Ωm and ΩT calculated with LightCone8 are questionable.
 
  • #106
  • #107
Hi @Jorrie and @pbuk,

Would you please let me know where in Jorrie 2021 calculator the circled number shown below is calculated and printed, for example, lines numbers in Calculation.js. I am trying to understand the discrepancy discussed in Post #105.

1657159866487.png
 
  • #108
It is calculated in the main html program, not in Calculate.js

line 356 var OmegaM = (Omega-Ynow * Ynow / Yinf / Yinf) * s_eq / (1+s_eq);

I'm not sure if this should have been "z_eq / (1+z_eq) "
Also take note that it is expressly rounded to 4 decimals for that calculation.
When calculated later in the tables, it is rounded to the requested number pf decimals.

Ps: The densities for the tables are calculated in
Calculation.js line 27: var Om = (Omega - Ol) * (s_eq + 1) / (s_eq + 2);
The (s_eq + 1) / (s_eq + 2) is a mistake that has been prviously pinted out and corrected in Lightcone8 by @pbuk. There is some further processing in lines 243 to 250.
These line numbers are only relevant to the LightCone7-2021-03-12 Version
 
Last edited:
  • #109
Jorrie said:
It is calculated in the main html program, not in Calculate.js . . .

Thanks! This is helpful. The situation is that using the same input, two different values of Ωm,0 are obtained from the calculator, 0.3089 from the main html program and 0.3090 from Calculation.js:

1657275186044.png


1657275224673.png

This suggests that there is an error in the calculator program. @pbuk
 
  • #110
JimJCW said:
This suggests that there is an error in the calculator program. @pbuk
I think the error is in the UI: we should have ## \Omega_{m,0} = \Omega - \Omega_{\Lambda,0} = 1 - 0.691 = 0.309 ##.
 
  • #111
pbuk said:
I think the error is in the UI: we should have ## \Omega_{m,0} = \Omega - \Omega_{\Lambda,0} = 1 - 0.691 = 0.309 ##.

In Calculation.js:

var Ok = 1 - Om - Or - Ol; // curvature density par
 
  • #112
pbuk said:
I think the error is in the UI: we should have ## \Omega_{m,0} = \Omega - \Omega_{\Lambda,0} = 1 - 0.691 = 0.309 ##.
I have checked the UI calculation and it seems to be right if radiation density is included, as it should.
##\Omega_{m,0} = 1-\Omega_{\Lambda,0} - \Omega_{r,0}= 1 - 0,691 - 0,000091637 = 0,308908363##
I obtained the value of ##\Omega_{r,0}## by substituting ##\Omega_{m,0} = S_{eq} \Omega_{r,0}## into the balancing equation.
On the other hand, if I set the columns for enough decimal places in Ligtcone8, ##\Omega_{T,0}## does not equal 1.

1657358364838.png

So the error seems to lie in calculation.js for the columns.
 
  • #113
Jorrie said:
I have checked the UI calculation and it seems to be right if radiation density is included, as it should.
##\Omega_{m,0} = 1-\Omega_{\Lambda,0} - \Omega_{r,0}= 1 - 0,691 - 0,000091637 = 0,308908363##
I obtained the value of ##\Omega_{r,0}## by substituting ##\Omega_{m,0} = S_{eq} \Omega_{r,0}## into the balancing equation.
On the other hand, if I set the columns for enough decimal places in Ligtcone8, ##\Omega_{T,0}## does not equal 1.

View attachment 303936
So the error seems to lie in calculation.js for the columns.

It's the same in LightCone7 (bar imprecision)
1657452255017.png

this isn't surprising as I've used essentially the same calculation as LightCone7
JavaScript:
          rholNow = rhocritNow * Ol;
          rhol = rholNow;
          rhomNow = rhoNow - rhol;
          rhom = rhomNow *s*s*s;
          rhorNow = rhomNow/s_eq;
          rhor = rhorNow *s*s*s*s;
i.e. ## \rho_{m,0} = \rho_{0} - \rho_{\Lambda,0} ##. I guess you are saying this should be ## \rho_{m,0} = \rho_{0} - \rho_{\Lambda,0} - \rho_{R,0} ##?

There's a few other oddities I'm coming across, I think I'm going to end up rewriting the physics from scratch (which means I'm going to have to learn it first!)
 
  • #114
pbuk said:
I guess you are saying this should be ## \rho_{m,0} = \rho_{0} - \rho_{\Lambda,0} - \rho_{R,0} ##?
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},$$
since ##\Omega := \rho/\rho_\mathrm{critical}##.
 
  • Like
Likes pbuk
  • #115
pbuk said:
There's a few other oddities I'm coming across, I think I'm going to end up rewriting the physics from scratch (which means I'm going to have to learn it first!)
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.
 
  • #116
Jorrie 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.
Minor corrections (red) in Calculation.js required to improve the issue:

var Ol = (Ynow / Yinf) * (Ynow / Yinf); // Lambda density parameter
var Om = (Omega - Ol) * s_eq / (s_eq + 1); // matter density parameter (corrected for radiation)
var Or = Om / s_eq; // Radiation density parameter (corrected for error; was /(s_eq+1)
var Ok = 1 - Om - Or - Ol; // curvature density par

rholNow = rhocritNow * Ol;
rhol = rholNow; // vacuum energy density remains constant
rhomNow = (rhoNow - rhol)*s_eq/(s_eq+1); // Matter energy density corrected for radiation
rhom = rhomNow *s*s*s; // Matter density at time T
rhorNow = rhomNow/s_eq; //radiation at present
rhor = rhorNow *s*s*s*s; // radiation density at time T
rhoT = rhol+rhom+rhor; // total energy density at time T
rhocrit = rhoConst*(H_t/secInGy)*(H_t/secInGy); // critical density at time T
OmegaMatterT = rhom/rhocrit; // Omegas at time T
OmegaLambdaT = rhol/rhocrit;
OmegaRadiationT = rhor/rhocrit;
OmegaTotalT = rhoT/rhocrit;
In Lightconne 7, it gives the correct matter density of 0.308908 at z=0 and a more accurate OmegaT. The drift in OmegaT may be rounding off in Lightcone 7. It will be interesting to see what it does in Lightcone8 with its improved calculation module.

1657527383446.png
 
Last edited:
  • #117
George Jones said:
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},$$
since ##\Omega := \rho/\rho_\mathrm{critical}##.
George, how do the equations change in the case where ##\Omega \ne 1##?
I'm asking because I don't think Lightcone7 gives the correct results in such a case.
 
  • #118
Jorrie said:
George, how do the equations change in the case where ##\Omega \ne 1##?
I'm asking because I don't think Lightcone7 gives the correct results in such a case.
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##.

Did you have other equations in mind?
 
  • #119
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##.

Did you have other equations in mind?
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:

Parameters at any particular time: we calculate these.
  • ## \Omega_{m} ## omegaM - density of mass as a fraction of the critical density.
  • ## \Omega_{\Lambda} ## omegaLambda - density of the cosmological constant as a fraction of the critical density.
  • ## \Omega_{rad} ## omegaRad - density of radiation as a fraction of the critical density.
  • ## \Omega ## omega - total density of [stuff] as a fraction of the critical density ## \Omega = \Omega_{m} + \Omega_{\Lambda} + \Omega_{rad} ##.
  • ## \Omega_{K} ## omegaK - Do we bother with this?
Parameters now: we measure these.
  • ## \Omega_{[m,0]} ## omegaM0 - density of mass now as a fraction of the critical density now.
  • ## \Omega_{[\Lambda,0]} ## omegaLambda0 - density of the cosmological constant now as a fraction of the critical density now.
  • ## \Omega_{[rad,0]} ## omegaRad0 - density of radiation now as a fraction of the critical density now.
  • ## \Omega_{0} ## 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]} ##.
  • ## \Omega_{[K,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} ##.
Now we have a very important equation from a computational point of view:
$$ [something] = \Omega_{[m,0]} s^3 + \Omega_{[rad,0]} s^4 + \Omega_{[\Lambda,0]} s^{3(1+w)} + \Omega_{[K,0]} s^3 $$
Yes I know that ## [something] = \frac{H^2}{H_0^2} ##, but we need a name for this: density parameter?
 
  • #120
pbuk said:
Now we have a very important equation from a computational point of view:
$$ [something] = \Omega_{[m,0]} s^3 + \Omega_{[rad,0]} s^4 + \Omega_{[\Lambda,0]} s^{3(1+w)} + \Omega_{[K,0]} s^3 $$
Yes I know that ## [something] = \frac{H^2}{H_0^2} ##, but we need a name for this: density parameter?
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.
 
  • Love
Likes pbuk

Similar threads

  • · Replies 15 ·
Replies
15
Views
2K
  • · Replies 100 ·
4
Replies
100
Views
7K
  • · Replies 19 ·
Replies
19
Views
3K
  • · Replies 18 ·
Replies
18
Views
2K
  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 17 ·
Replies
17
Views
2K
Replies
20
Views
2K
  • · Replies 0 ·
Replies
0
Views
3K
  • · Replies 8 ·
Replies
8
Views
3K
  • · Replies 0 ·
Replies
0
Views
2K