LightCone Calculator Improvements

  • Context: Undergrad 
  • Thread starter Thread starter Jorrie
  • Start date Start date
  • Tags Tags
    Calculator
Click For Summary

Discussion Overview

The discussion focuses on improvements to the LightCone calculator, particularly regarding the integration of the latest Planck data releases and the handling of cosmological parameters such as ##\Omega_m## and ##\Omega_\Lambda##. Participants explore potential UI enhancements, computational adjustments, and the implications of these changes on model accuracy and user experience.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • Some participants suggest adding options for displaying and downloading results in CSV and JSON formats for better model comparison.
  • There is a proposal to prioritize ##\Omega_m## over ##\Omega_\Lambda## as a base input, with ##\Omega_\Lambda## being treated as a derived parameter.
  • Participants discuss the inclusion of the latest Planck data releases and whether to include BAO data in the results.
  • One participant notes a discrepancy between their derived ##\Omega_m## and the Planck values, suggesting a need to revise their conversion approach.
  • Concerns are raised about the implications of using a flat model where ##\Omega_m + \Omega_\Lambda = 1##, particularly regarding the treatment of radiation density in the universe.
  • There is mention of a potential cache issue affecting the functionality of the LightCone calculator, with suggestions for improving version control.
  • Participants agree that the core computation module should calculate ##\Omega_{\Lambda,0}## from ##\Omega_{m,0}## if not provided, although UI changes are still pending.

Areas of Agreement / Disagreement

Participants express multiple competing views regarding the treatment of cosmological parameters and the implications of their choices on model accuracy. The discussion remains unresolved on several technical aspects, particularly concerning the integration of radiation density and the handling of derived parameters.

Contextual Notes

There are limitations regarding the assumptions made about the cosmological model, particularly in relation to the treatment of ##\Omega_{rad}## and the implications of a flat universe model. The discussion also highlights unresolved mathematical steps related to the integration of new data and parameters.

Who May Find This Useful

This discussion may be useful for developers and users of the LightCone calculator, cosmologists interested in the implications of parameter choices, and those involved in the analysis of cosmological data from Planck missions.

  • #91
I don't know the ICRAR calculator. I see it can produce graphs, but numerically it looks like a very advanced one-shot-z calculator of professional quality and accuracy. I think one-shot makes things considerably easier and faster.

Lightcone8's algorithm can possibly be more optimized, but for its intended purpose, as a relatively easy to use educational tool, I doubt if it is worth the effort needed for pursuing the ultra-high-z regime.
 
  • Like
Likes   Reactions: pbuk
Space news on Phys.org
  • #92
I seem to remember the ICRAR calculator changes the model to radiation only for very early redshifts, as Burt suggested a few posts back. There are a few other differences that may be worth investigating, and one thing that definitely needs looking at is the target error for the integration. This all needs work at a lower level than via the LightCone GUI so if you are interested I suggest you set up a NodeJS development environment and play with the underlying model which lives at https://github.com/cosmic-expansion/cosmic-expansion-js.
 
  • #93
pbuk said:
I seem to remember the ICRAR calculator changes the model to radiation only for very early redshifts, as Burt suggested a few posts back.

I wouldn’t say that the ICRAR calculator changes the model to radiation only for vert early redshifts. Instead, I would say that for high z values, the radiation term becomes dominating in both the ICRAR calculator and LightCone8:

1661137074621.png


1661137102917.png


By the way, where can I find Burt’s post?

@Jorrie
 
  • #94
Jorrie said:
I don't know the ICRAR calculator. I see it can produce graphs, but numerically it looks like a very advanced one-shot-z calculator of professional quality and accuracy. I think one-shot makes things considerably easier and faster.

The ICRAR result shown in Post #90 suggests that the computation time using that calculator remains the same even for z = 1050, but using LightCone8, it increases by a factor of 10 when z = 106. It is a little peculiar, but not crucial.

Taking your result into consideration, we can use ‘zupper > zlower to 300000’ as permitted range for Upper row redshift. At z = 300000, ΩR,0 already becomes very dominating (see Post #93).

@pbuk
 
  • #95
JimJCW said:
Taking your result into consideration, we can use ‘zupper > zlower to 300000’ as permitted range for Upper row redshift. At z = 300000, ΩR,0 already becomes very dominating (see Post #93).
I have left zupper at 1e6, but included a recommendation for 3e5. There is also an indicator that the integration is running for those up to 1e6 values.
http://jorrie.epizy.com/docs/index.html?i=1
This link will remain the same from one X version to the next. When we accept the version as valid, we can bump it up to the main branch.
 
  • #96
JimJCW said:
I wouldn’t say that the ICRAR calculator changes the model to radiation only for vert early redshifts.
I don't see how you can establish that by looking at the outputs, you need to inspect the code which you can see by clicking the "R Code" tab on the ICRAR site (although it may actually be the code at https://github.com/asgr/celestial/blob/master/R/cosgrow.R). Having said that, it does look as though it doesn't change the integrand for high z.

As I say if you want to investigate what is causing the slowdown you need to work with the underlying model and try adjusting the epsilon parameter to the integration which controls relative error and is currently set to ## 10^{-8} ##, and also look at the full return value from the integrator to see the number of steps that are taken.

None of this is near the top of my priority list because I believe the current code achieves the objectives for the LightCone application.
 
Last edited:
  • #97
pbuk said:
I don't see how you can establish that by looking at the outputs, you need to inspect the code which you can see by clicking the "R Code" tab on the ICRAR site (although it may actually be the code at https://github.com/asgr/celestial/blob/master/R/cosgrow.R). Having said that, it does look as though it doesn't change the integrand for high z.

As I say if you want to investigate what is causing the slowdown you need to work with the underlying model and try adjusting the epsilon parameter to the integration which controls relative error and is currently set to ## 10^{-8} ##, and also look at the full return value from the integrator to see the number of steps that are taken.

None of this is near the top of my priority list because I believe the current code achieves the objectives for the LightCone application.

In Post #22, it is demonstrated that the calculation results from Lightcone8 and ICRAR are consistent for z = 0.02. A similar conclusion can be reached for z = 300000:

LightCone8
ICRAR
z300000300000
Scale (a)3.33332222E-063.33332222E-06
T Gyr8.34828635E-098.34837088E-09
R Gpc5.10964255E-09
Dnow Gpc1.41602035E+011.41602035E+04
Dthen Gpc4.72005209E-054.72005209E-02
DHor Gpc5.10964255E-09
Dpar Gpc5.12398784E-09
Vgen/c2.89051673E+03
Vnow/c3.19580877E+00
Vthen/c9.23753872E+03
H(z)5.86719042E+105.86719042E+10
Temp K8.17646726E+05
rho kg/m36.46598880E-096.46643447E-09
OmegaM1.11671814E-021.11671814E-02
OmegaL9.16135695E-199.16135695E-19
OmegaR9.88832819E-019.88832819E-01
OmegaT1.000000000E+001.000000000E+00

This result suggests that the ICRAR calculator uses all three parameters, Ωm, ΩΛ, and ΩR even for high z values, just like LightCone8.

I have been a happy user of LightCone calculator(s) and am now very happy with LightCone8.

I think we are only trying to tighten some loose ends, right?

@Jorrie
 
  • #98
JimJCW said:
I think we are only trying to tighten some loose ends, right?
Yup and at the same time we have opened the range of usability quite a bit. Lightcone7 was limited to zupper of 20,000. With Lightcone8 we are now confident with upper of 300,000 and 1,000,000 at a stretch (1 year age).

Plus the future expansion capability has doubled and we have an accurate cosmological horizon calculation value that many calculators lack.

Team effort paying off... Thanks guys :smile:
 
  • #99
Hi @Jorrie,

What is the status of LightCone8 Cosmological Calculator (v8.3.x) at http://jorrie.epizy.com/docs/? It still gives incorrect Dhor (Ro and Dhor overlap):

1662209414852.png


Please see Post #69.
 
  • #101
Jorrie said:
It may just be a cashed issue, . . .

You are right. It works for me too.
 

Similar threads

  • · Replies 61 ·
3
Replies
61
Views
5K
  • · Replies 18 ·
Replies
18
Views
2K
  • · Replies 7 ·
Replies
7
Views
3K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 0 ·
Replies
0
Views
4K
  • · Replies 0 ·
Replies
0
Views
3K
  • · Replies 3 ·
Replies
3
Views
3K
  • · Replies 15 ·
Replies
15
Views
6K
  • · Replies 11 ·
Replies
11
Views
2K
  • · Replies 1 ·
Replies
1
Views
3K