LightCone Calculator Improvements

[Jorrie]

TL;DR Summary

LightCone8 has just been released with a number of glitch fixes (see "A glitch in Jorrie's Cosmo-Calculator").
This is a continuation of that thread , where some improvements have been discussed
We now have a core team looking after it, namely: @Jorrie, @pbuk and @JimJCW and a number of improvements are under discussion.

Re: "A glitch in Jorrie's Cosmo-Calculator"
LightCone8 has just been released with a number of glitch-fixes.
We now have a core team looking after it, namely: @Jorrie , @pmbuk and @JimJCW.
Here is the last post from the referenced thread.

Thanks, of course the UI only displays a maximum 9 digits, the results at full precision are:
---
A useful feature for the UI would be display and/or download in CSV and/or JSON format of the full precision results.

Could be nice to have for model comparison, but we know the cosmological inputs to no better than the 4th digits, the main constraint being $H_0$. A more important UI change would be to have the latest (2018/2021) Planck data release as an option.

Historically, LightCone concentrated on the $H_0$ and $\Omega_\Lambda$ as base inputs. This was partially because the late @marcus had a lot of threads explaining the usefulness of having $\Omega_\Lambda$ as a parameter.

However, the Planck base group of sampled data does not include $\Omega_\Lambda$, but rather the two matter densities: baryonic and dark - see Table 2 on page 16 in the paper (partially shown below) - which they then statistically add together to get $\Omega_m$.
So $\Omega_\Lambda$ is a derived parameter in their books.

In the past data releases, we took the LightCone inputs from the last row of the second group of derived inputs in Table 2.
I suggest that we keep on doing that, except for giving priority to $\Omega_m$ rather than to $\Omega_\Lambda$, the latter then becoming a derived parameter.

 

[pbuk]

[csv/json display/download of results] could be nice to have for model comparison, but we know the cosmological inputs to no better than the 4th digits, the main constraint being $H_0$.

Yes you are right - this is more for verification/debugging purposes than for end user functionality - I may knock something up separate from the LightCone site.

A more important UI change would be to have the latest (2018/2021) Planck data release as an option.

Yes: which of the result sets should we include, with or without BAO data? Or both?

However, the Planck base group of sampled data does not include $\Omega_\Lambda$, but rather the two matter densities: baryonic and dark - see Table 2 on page 16 in the paper (partially shown below) - which they then statistically add together to get $\Omega_m$.

I think there is also a neutrino contribution included in $\Omega_m$.

I suggest that we keep on doing that, except for giving priority to $\Omega_m$ rather than to $\Omega_\Lambda$, the latter then becoming a derived parameter.

That makes sense to me, I assume there is no cosmological reason not to do that? We then have
$$ \Omega_{\Lambda,0} = \Omega_{0} - \frac{s_{eq} + 1}{s_{eq}} \Omega_{m,0} $$

 

[Jorrie]

Yes: which of the result sets should we include, with or without BAO data? Or both?

Ok I see, they are using the column without BAO for their Base data, so I guess we follow suite.

That makes sense to me, I assume there is no cosmological reason not to do that? We then have

$$ \Omega_{\Lambda,0} = \Omega_{0} - \frac{s_{eq} + 1}{s_{eq}} \Omega_{m,0} $$

I can see no reason why this would not be cosmologically correct.

I will work on it a little over the weekend.

 

[pbuk]

I have made the following changes:

• the core computation module will now calculate $\Omega_{\Lambda,0}$ from $\Omega_{M,0}$ if the former is not provided (I have not changed the UI to put this into effect yet though).

• the core module now includes the constant for conversion between parsecs and light years at machine precision: 1 parsec $\frac{969,394,202,136,000}{94,607,304,725,808\pi} \approx 3.2615 63777 16743 37$ light years; I have changed the UI to use this so @JimJCW can cross-check to ICRAR now.
• I have fixed the duplication of $z = 0$ if this was the start or end of a range.

Please note you should see "LightCone v8.1.1 | CosmicExpansion v1.1.0" at the bottom of the web page, if not hold shift and click the refresh icon (or hit Ctrl-F5).

 

[Jorrie]

Thanks pbuk. I will change the UI for this and also add the latest Planck values as an option.

Edit- PS: while working on the latter, I noticed that there is a 4th digit difference between our presently derived $\Omega_m$ and their value with the same $\Omega_\Lambda$ value. Hence I suggest we scrap our present conversion and take both $\Omega_m$ and $\Omega_\Lambda$ as inputs.

 

[JimJCW]

Please note you should see "LightCone v8.1.1 | CosmicExpansion v1.1.0" at the bottom of the web page, if not hold shift and click the refresh icon (or hit Ctrl-F5).

None of these works for me. Please help!

The old LightCone8 gives me the following:

 

[Jorrie]

I used https://light-cone-calc.github.io/ and got the following

Try and run it again with shift-refresh

Also works with Gpc

 

[pbuk]

Thanks pbuk. I will change the UI for this and also add the latest Planck values as an option.

Edit- PS: while working on the latter, I noticed that there is a 4th digit difference between our presently derived $\Omega_m$ and their value with the same $\Omega_\Lambda$ value. Hence I suggest we scrap our present conversion and take both $\Omega_m$ and $\Omega_\Lambda$ as inputs.

I don't think we can do that because at the reported level of precision $\Omega_m + \Omega_\Lambda = 1$ which would mean we have to have $\Omega_{rad} = 0$. In order to have any radiation in the Universe at all now we must have $\Omega_{rad,0} = \frac{\Omega_{m,0}}{s_{eq}}$ and therefore from $\Omega_{\Lambda,0} = \Omega_{0} - \Omega_{m,0} - \Omega_{rad,0}$ we get

$$ \Omega_{\Lambda,0} = \Omega_{0} - \frac{s_{eq} + 1}{s_{eq}} \Omega_{m,0} $$

I suppose we could 'distribute' $\Omega_{rad,0}$ between $\Omega_{\Lambda,0}$ and $\Omega_{m,0}$. I will look further into the calculations of ICRAR but I think they use the (to me) mysterious $\sigma_8$ which complicates matters.

 

[Jorrie]

Thanks pbuk. I will change the UI for this and also add the latest Planck values as an option.

Edit- PS: while working on the latter, I noticed that there is a 4th digit difference between our presently derived $\Omega_m$ and their value with the same $\Omega_\Lambda$ value. Hence I suggest we scrap our present conversion and take both $\Omega_m$ and $\Omega_\Lambda$ as inputs.

I think we need some help from a cosmologist here. The Planck 2018 baseline values for the two main density parameters add up to 1 identically, leaving no room for radiation density in a $\Omega=1$ flat model. This probably means that the curvature is hidden in the error bars.

But the radiation density could not have been negligible in the early universe.
For LightCone8 purposes, shall we just calculate its present value as $\Omega_r =\Omega_m/(1+z_{eq})$ and accept that we model a marginally closed universe, or should we have a different approach?

Ps: seems our two posts crossed in the mail...

 

[JimJCW]

I used https://light-cone-calc.github.io/ and got the following

View attachment 304761
Try and run it again with shift-refresh

Also works with Gpc

I just used https://light-cone-calc.github.io/ and got the following:

P.S.: I changed browser. It worked like you said. It could be cache problem.

 

[pbuk]

P.S.: I changed browser. It worked like you said. It could be cache problem.

Yes: the browser caches the back end calculation module for 1 week. We could change this by requesting a specific version of the back end module rather than the latest version, and probably should.

 

[Jorrie]

We have just activated LightCone v8.2.0. with the Planck 2018 Baseline Dataset as default and also the Base+ BAO as an option. Link in my sig (remaining the same)

 

[JimJCW]

Using Ω_Λ,0, Ω_m,0, or Ω_R,0 as input:

We can use anyone of the three Ω’s as input, but not more than one. This is because they are related by two equations:

Given the value of anyone of them, the values of the other two are determined by the above equations:

As examples, if we set Ω₀ = 0 and z_eq = 3370, we get the following results, with input quantities boldfaced:

 

[pbuk]

Using Ω_Λ,0, Ω_m,0, or Ω_R,0 as input:

We can use anyone of the three Ω’s as input, but not more than one. This is because they are related by two equations:

Yes indeed. This is implemented in the back end calculations like this:

• $z_{eq}$ must always be provided
• if $\Omega_{\Lambda,0}$ is provided it uses that to calculate $\Omega_{m,0}$, otherwise $\Omega_{m,0}$ must be provided*
• $\Omega_{rad,0}$ is calculated from $\Omega_{m,0}$

    // Use omegaLambda0 if it is provided.
    if (props.omegaLambda0 != null) {
      omegaLambda0 = props.omegaLambda0;
      omegaM0 = (omega0 - omegaLambda0) * (sEq / (sEq + 1));
    } else if (props.omegaM0 != null) {
      omegaM0 = props.omegaM0;
      omegaLambda0 = omega0 - omegaM0 * ((sEq + 1) / sEq);
    } else {
      throw new Error('Must provide either omegaM0 or omegaLambda0');
    }

    const omegaRad0 = omegaM0 / sEq;

(source)

However note that only $\Omega_{\Lambda,0}$ is currently editable in the UI.

 

[Jorrie]

Using ΩΛ,0, Ωm,0, or ΩR,0 as input:

We can use anyone of the three Ω’s as input, but not more than one. This is because they are related by two equations:

Given the value of anyone of them, the values of the other two are determined by the above equations:

As far as the density parameters go, we must not forget that $\Omega_0$ does not have to be 1, so we actually have 4, of which we have to know at least 2. At Present, Planck data supplies us with $\Omega_{m,0}$ and $\Omega_{\Lambda,0}$, but we take $\Omega_{\Lambda,0}$ and assume $\Omega_0$ in order to find $\Omega_{m,0}$ and $\Omega_{R,0}$.
Taken at face value, $\Omega_0$ should then exceed 1 by a small margin - @pbuk has suggested that we split $\Omega_{R,0}$ and absorb it 50:50 (?) into the two given values to ensure $\Omega_0 = 1$.
But is this good practice? Future tests may give $\Omega_0 \ne 1$.

If any resident cosmologist is not on summer vacation, some advice will be helpful.

 

[George Jones]

As far as the density parameters go, we must not forget that $\Omega_0$ does not have to be 1, so we actually have 4, of which we have to know at least 2. At Present, Planck data supplies us with $\Omega_{m,0}$ and $\Omega_{\Lambda,0}$, but we take $\Omega_{\Lambda,0}$ and assume $\Omega_0$ in order to find $\Omega_{m,0}$ and $\Omega_{R,0}$.

Yes, to specify an arbitrary (i.e., not necessarily spatially flat) FLRW universe, 4 parameters are needed. Typically, these are taken conceptually to be: $H_0$; $\Omega_{r,0}$; $\Omega_{m,0}$; and $\Omega_{\Lambda,0}$. Any equivalent set could be used. One example of an equivalent set: $1/H_0$; $\Omega_0$; $\Omega_{m,0}$; and $s_{eq}$. Here, $1/H_0$ is the Hubble time. There are loads of other equivalent sets.

The 4 parameters can be supplied by some combination of user input and internal program code, but 4 need to be specified.

 

[pbuk]

Yes this is true, but the

Yes, to specify an arbitrary (i.e., not necessarily spatially flat) FLRW universe, 4 parameters are needed. Typically, these are taken conceptually to be: $H_0$; $\Omega_{r,0}$; $\Omega_{m,0}$; and $\Omega_{\Lambda,0}$. Any equivalent set could be used. One example of an equivalent set: $1/H_0$; $\Omega_0$; $\Omega_{m,0}$; and $s_{eq}$. Here, $1/H_0$ is the Hubble time. There are loads of other equivalent sets.

The 4 parameters can be supplied by some combination of user input and internal program code, but 4 need to be specified.

To summarise:

• LightCone8 currently uses $\{ H_0, \Omega_{0}, \Omega_{\Lambda,0}, z_{eq} \}$
• I don't think we can use $\{ H_0, \Omega_{0}, \Omega_{m,0}, \Omega_{\Lambda,0} \}$ because at the quoted precision for all survey data $\Omega_{m,0} + \Omega_{\Lambda,0} = 1$ and so we would model a flat Universe with no radiation: given that this data is computed from the CMB that would be somewhat ironic.
• Basically it boils down to what do we do with $\Omega_{rad,0} \approx 0.000093$; do we take it off $\Omega_{m,0}$, decreasing it by 295 ppm so it becomes ~0.315207 (this is what we do now)? Do we take it off $\Omega_{\Lambda,0}$, decreasing it by 136 ppm so it becomes ~0.684607? Or do we decrease both by 93 ppm? From the point of view of "doing the least harm" surely this is best?

 

[Jorrie]

Or do we decrease both by 93 ppm? From the point of view of "doing the least harm" surely this is best?

I support this option, so unless there is a good technical obstacle, I think we must implement it.

I propose that we leave the GUI parameters as per the Planck source's values and use the radiation correction in the backend. It has significant influence at early times.

 

[George Jones]

Yes this is true, but the

To summarise:

• LightCone8 currently uses $\{ H_0, \Omega_{0}, \Omega_{\Lambda,0}, z_{eq} \}$
• I don't think we can use $\{ H_0, \Omega_{0}, \Omega_{m,0}, \Omega_{\Lambda,0} \}$ because at the quoted precision for all survey data $\Omega_{m,0} + \Omega_{\Lambda,0} = 1$ and so we would model a flat Universe with no radiation: given that this data is computed from the CMB that would be somewhat ironic.
• Basically it boils down to what do we do with $\Omega_{rad,0} \approx 0.000093$; do we take it off $\Omega_{m,0}$, decreasing it by 295 ppm so it becomes ~0.315207 (this is what we do now)? Do we take it off $\Omega_{\Lambda,0}$, decreasing it by 136 ppm so it becomes ~0.684607? Or do we decrease both by 93 ppm? From the point of view of "doing the least harm" surely this is best?

Why does $\Omega_0$ identically equal to one need to be manitained?

 

[JimJCW]

To summarise:

• LightCone8 currently uses $\{ H_0, \Omega_{0}, \Omega_{\Lambda,0}, z_{eq} \}$
• I don't think we can use $\{ H_0, \Omega_{0}, \Omega_{m,0}, \Omega_{\Lambda,0} \}$ because at the quoted precision for all survey data $\Omega_{m,0} + \Omega_{\Lambda,0} = 1$ and so we would model a flat Universe with no radiation: given that this data is computed from the CMB that would be somewhat ironic.
• Basically it boils down to what do we do with $\Omega_{rad,0} \approx 0.000093$; do we take it off $\Omega_{m,0}$, decreasing it by 295 ppm so it becomes ~0.315207 (this is what we do now)? Do we take it off $\Omega_{\Lambda,0}$, decreasing it by 136 ppm so it becomes ~0.684607? Or do we decrease both by 93 ppm? From the point of view of "doing the least harm" surely this is best?

I think LightCone8 uses the following six parameters: H₀, Ω_Λ,0, Ω_m,0, Ω_R,0, Ω_k,0 (= 1 - Ω₀), and z_eq.

If the values of H₀, Ω₀, and z_eq are set as being done in LightCone8, we need the values of Ω_Λ,0, Ω_m,0, and Ω_R,0 to make various calculations. We can only use one of them as input because the values of the other two parameters are determined by the following relations (see Post #13):

If we really want to use both Ω_Λ,0 and Ω_m,0 as inputs, we can change z_eq to a derived quantity and use the following equations to find the values of Ω₀ and z_eq from Ω_Λ,0 and Ω_m,0:

Note that it will be very hard to get Ω₀ = 1 in this case.
@Jorrie

 

[Jorrie]

I think LightCone8 uses the following six parameters: H0, ΩΛ,0, Ωm,0, ΩR,0, Ωk,0 (= 1 - Ω0), and zeq.

Correct, but Ω_R,0 and Ω_k,0 are derived, so I proposed that we take the other 4 as inputs in the next update. They are also the 4 provided specifically by the Planck data releases.

The apparent problem of their Ω_Λ,0 and Ω_m,0 totaling 1 is probably just a matter of Ω_R,0 being smaller than the uncertainties on the other two.
We still have to decide how to best handle that uncertainty in Lightcone8.

 

[JimJCW]

Correct, but Ω_R,0 and Ω_k,0 are derived, so I proposed that we take the other 4 as inputs in the next update. They are also the 4 provided specifically by the Planck data releases.

The apparent problem of their Ω_Λ,0 and Ω_m,0 totaling 1 is probably just a matter of Ω_R,0 being smaller than the uncertainties on the other two.

We still have to decide how to best handle that uncertainty in Lightcone8.

In Planck 2018 results. I, in both Tables 6 and 7 and for both cases of ‘Planck alone’ and ‘Planck + BAO’,

Ω_Λ,0 + Ω_m,0 = 1​

It seems we don’t need to use both Ω_Λ,0 and Ω_m,0 as inputs at the same time.

I think LightCome8 is functioning properly using Ω_Λ,0 and z_eq as inputs. It calculates Ω_m,0 and Ω_R,0 in the program correctly (see Post #148 of the thread, A glitch in Jorrie’s Cosmo-Calculator?). It can also be demonstrated that the calculation results from Lightcone8 and ICRAR are consistent (see Post 153 of the thread mentioned):

	LightCone8​	ICRAR​
z	0.02	0.02
Scale (a)	9.803921569E-01	9.803921569E-01
T Gyr	1.351246087E+01	1.351276116E+01
R Gpc	4.384362823E+00
Dnow Gpc	8.810076113E-02	8.810076113E-02
Dthen Gpc	8.637329523E-02	8.637329523E-02
DHor Gpc	4.384362823E+00
Dpar Gpc	1.381871578E+01
Vgen/c	9.896208856E-01
Vnow/c	1.990692361E-02
Vthen/c	1.970030737E-02
H(z)	6.837765717E+01	6.837765717E+01
Temp K	2.779989600E+00
rho kg/m3	8.782193743E-27	8.782799071E-27
OmegaM	3.217304253E-01	3.217304253E-01
OmegaL	6.781722253E-01	6.781722253E-01
OmegaR	9.734946123E-05	9.734946125E-05
OmegaT	1.000000000E+00	1.000000000E+00

If we want, we can put the calculated Ω_R,0 value as output under ‘Matter density parameter, Ω_m’,

If we want, we can also use Ω_m,0 and z_eq as inputs instead of Ω_Λ,0 and z_eq (see Post #13 of this thread).

 

[pbuk]

Or do we decrease both by 93 ppm? From the point of view of "doing the least harm" surely this is best?

I support this option, so unless there is a good technical obstacle, I think we must implement it.

Actually I've thought about this again. It seems to me as a layman that the surveys calculate $\Omega_{\Lambda,0}$ as "the amount of dark energy that is needed to account for expansion once we have taken account of 'ordinary' mass-energy" ##. From this point of view, the current calculations (where we reduce the amount of matter to make room for radiation within the 'ordinary' mass-energy) are correct.

... the late @marcus had a lot of threads explaining the usefulness of having $\Omega_\Lambda$ a parameter.

Was this what @marcus had in mind?

It can also be demonstrated that the calculation results from Lightcone8 and ICRAR are consistent

Another vote for maintaining the status quo.

 

[Jorrie]

Was this what @marcus had in mind? Yes, I think soAnother vote for maintaining the status quo. Agreed.

In the future, we may perhaps have the more sophisticated selection that you have proposed before, so that we can match the inputs used by other models.

 

[JimJCW]

In Planck 2018 results. I, in both Tables 6 and 7 and for both cases of ‘Planck alone’ and ‘Planck + BAO’,

Ω_Λ,0 + Ω_m,0 = 1​

It seems we don’t need to use both Ω_Λ,0 and Ω_m,0 as inputs at the same time.

If Ω_Λ,0 and Ω_m,0 are treated as inputs at the same time, using PLANCK(2018+BAO) data as an example, we will have the following:

Note that the space is not flat in this case.

Some of the above numbers can be obtained using LightCone8:

Ω0​	z​	zeq​	OmegaM​	OmegaL​	OmegaR​	OmegaT​
1​	0​	3387​	0.311008203​	0.6889​	0.000091797​	1​
1.000091824​	0​	3387​	0.3111​	0.6889​	0.000091824​	1.000091824​

@Jorrie, @pbuk

 

[Jorrie]

I have done a variation on the Input and Conversion UI sections, showing both $\Omega_L$ and $\Omega_M$ on the left as inputs, with $\Omega_R$ on the right as a conversion. This makes no difference to the present tabular output, "where we reduce the amount of matter to make room for radiation within the 'ordinary' mass-energy" - (@pbuk). The only advantage is that the variant UI shows the "official" $\Omega_M$ that the Planck 2018 data release provides us with and not the reduced one.

The variant has the added attraction of a machine precision CSV output option.
It sits at the top of my Github fork, but presently I do not know how to link to it. @pbuk please help...

 

[pbuk]

@pbuk please help...

I haven't got access to my development machine until tonight, in the meantime you could try creating a pull request against the upstream develop branch.

 

[Jorrie]

I haven't got access to my development machine until tonight, in the meantime you could try creating a pull request against the upstream develop branch.

I'm still unsure on how to give other interested Forum members a link to run the IO variant without bumping it up.

The best I could figure is to give then this Github url from where they can click "code" and then download a ZIP for installing a directory on their own computer and then run the .exe...

Is their a simpler method to give them a run-able version link?

 

[pbuk]

I'm still unsure on how to give other interested Forum members a link to run the IO variant without bumping it up.

The best I could figure is to give then this Github url from where they can click "code" and then download a ZIP for installing a directory on their own computer and then run the .exe...

Is their a simpler method to give them a run-able version link?

Yes, if you got to your repo at https://github.com/burtjordaan/light-cone-calc.github.io and select Settings -> Pages, then make it look like this:

You should then (after a short delay to build it) see your version of the site at https://burtjordaan.github.io/light-cone-calc.github.io

 

[JimJCW]

Discrepancy in LightCone8.1.2 – Jorrie:

When running LightCone8.1.2 – Jorrie using PLANCK(2018+BAO) data, I noticed that the input value,

Ω_m,0 = 0.3111​

is changed in output:

Ω_m,0 = 0.3110082030​

For a related discussion, please see Post #25.

@Jorrie, @pbuk

 

[Jorrie]

This is as expected. See my post #26. Either Ω_m,0 or Ω_Lambda,0 has to give if we want to keep Omega_T,0=1.

 

[pbuk]

Yes, if you got to your repo at https://github.com/burtjordaan/light-cone-calc.github.io and select Settings -> Pages, then make it look like this:
View attachment 305226
You should then (after a short delay to build it) see your version of the site at https://burtjordaan.github.io/light-cone-calc.github.io

Note that with the current settings @Jorrie's development fork is served at https://burtjordaan.github.io/light-cone-calc.github.io/docs/.

 

[Jorrie]

Note that with the current settings @Jorrie's development fork is served at https://burtjordaan.github.io/light-cone-calc.github.io/docs/.

Thanks for providing the runable link, because I still have finger trouble with Github. Note that this is not the latest version, which JimJCW (somehow) got hold of, albeit with the actual OutputCSV.js missing - Github seems to be a difficult animal to understand at my age...

 

[JimJCW]

Note that this is not the latest version, which JimJCW (somehow) got hold of, ...

I got it from Post #7: https://light-cone-calc.github.io/

 

[JimJCW]

This is as expected. See my post #26. Either Ω_m,0 or Ω_Lambda,0 has to give if we want to keep Omega_T,0=1.

I think if at input Ω_m,0 = 0.3111 but at output it becomes Ω_m,0 = 0.3110082030, it is a discrepancy.

ICRAR, in this situation, gives,

The space will not be flat in this case.