LightCone Calculator Improvements

[Jorrie]

Maybe cache problem, but although it shows version 8.3, the changes for correcting Dhor have not pulled through. Strange.
Outputs updated: 2022-08-16 15:36:10

Copyright © 2009-2022 jorrie.epizy.com | AGPL license | LightCone v8.3.0 | CosmicExpansion v1.1.1

 

[pbuk]

Maybe cache problem

Oops, no it was me (updated the calculations, forgot to update the UI). Fixed now.

 

[Jorrie]

 

[Jorrie]

Since we now have a seemingly well behaved Lightcone8, e.g.

I decided to stress test it a little. By simply turning the knob labeled Omega_L down well below the stated minimum, namely to 0.0001, and expanding the range of the graph by trial and error, I've got this amazing result (from both a programatical and perhaps a cosmological POV):

If true, it shows the amazing performance of @pbuk's new calculation module and also the fact that even a relatively tiny Omega_L still points to the fact that the Hubble radius R₀ and the cosmological horizon approach each other well beyond 2 trillion years.

Perhaps @JimJCW (our master tester) can advise us how far we can relax the input ranges before we run into gross inaccuracies.

 

[pbuk]

If true, it shows the amazing performance of @pbuk's new calculation module

Perhaps @JimJCW (our master tester) can advise us how far we can relax the input ranges before we run into gross inaccuracies.

actually I'm pretty confident in the integration now: the functions become very smooth as $t \to \infty$ and the integration uses the transformation $$ f'(x) = \frac{f \left (a + \frac{1}{1-t} \right )}{(1-t)^2} \implies \int_a^\infty f(x) dx = \int_0^1 f'(x) dx $$ to deal with the improper integral.

 

[JimJCW]

. . . how far we can relax the input ranges before we run into gross inaccuracies.

In LightCone7:

In LightCone8.3:

Note that in LightCone8.3, the range specification, ‘>0.001 to 1.00’, does not work. The specification in LightCone7, ‘>0 to 1.00’, seems to be more suitable.

In ICRAR, Ω_Λ,0 can be set to 0 or a small value such as 0.000000001:

@pbuk

 

[pbuk]

Note that in LightCone8.3, the range specification, ‘>0.001 to 1.00’, does not work. The specification in LightCone7, ‘>0 to 1.00’, seems to be more suitable.

The test is simply that it is greater than 0 so the text should probably be changed, yes. Setting it to 0 seems to prevent the integration converging (probably because the Physics says it doesn't but I can't think exactly why at the moment).

 

[Jorrie]

The test is simply that it is greater than 0 so the text should probably be changed, yes. Setting it to 0 seems to prevent the integration converging (probably because the Physics says it doesn't but I can't think exactly why at the moment).

Yes $\Omega_\Lambda>0$ is correct for the programming as it stands. I will change the input text.
When $\Omega_\Lambda= 0$, there does not exist a cosmological event horizon - this is probably why the integration does not converge in that case.

 

[Jorrie]

While on the topic of stretching the input boundaries (ranges), a few others can possibly also be changed to allow for more broad comparison with other cosmo-calculators. I'm thinking of z_upper up to a million and z_lower to >-1, e.g.,

Any others?

Edit: possibly with a warning that a very high z_upper may cause slow processing on laptops, tablets etc.

 

[pbuk]

I don't think high z is a problem anyway, we already integrate to infinity to get $t_0$.

 

[Jorrie]

I don't think high z is a problem anyway, we already integrate to infinity to get $t_0$.

For some reason I find a severe slowdown when starting z at 1E6, possibly because of the table that takes longer for larger ranges.

 

[Jorrie]

For some reason I find a severe slowdown when starting z at 1E6, possibly because of the table that takes longer for larger ranges.

Perhaps the excessive slowdown for more severe ranges could be effected by the internet speed. As a test, I opened up the z range from -0.9999 to 1 000 000 and got between 10 and 15 seconds delay before the result table was presented. On my end I'm on a 50 Mbps fiber, but there are some intercontinental delays as well.

If I understand it correctly, your integration routine does not run locally, but on some remote server? If so, a large number of requests need to go to it, I guess.

For what it's worth, if it would be workable, it gave the following range in cosmic time:

That's from less than one year, way out to 173 Gyr...

 

[pbuk]

If I understand it correctly, your integration routine does not run locally, but on some remote server? If so, a large number of requests need to go to it, I guess.

No, it's all running in the local machine. I think the problem may be seeking too high a precision at extreme redshifts.

 

[JimJCW]

For some reason I find a severe slowdown when starting z at 1E6, possibly because of the table that takes longer for larger ranges.

Where or how can I try the calculator?

 

[Jorrie]

Where or how can I try the calculator?

http://jorrie.epizy.com/docs/index.html

I'm still struggling to get a working link out of my fork for direct use on github
I have marked it v8.3.x

 

[JimJCW]

For some reason I find a severe slowdown when starting z at 1E6, possibly because of the table that takes longer for larger ranges.

The value z = 1000000 is unusual (I don't know why); it takes more than 10 sec to get my calculation result. For other values, such as z = 99999.99999, it takes only a fraction of a sec. You could change the range to,

> z_lower to 99999​

 

[Jorrie]

The value z = 1000000 is unusual (I don't know why); it takes more than 10 sec to get my calculation result. For other values, such as z = 99999.99999, it takes only a fraction of a sec.

I don't find z = 1000000 (1 million) to be special. It seems the calc time goes up exponentially with large z. Up to z = 300000 it seems to stay within 1 second execution time. This gives around 8 years after T = 0.

There is of course a different route that can be followed for times shortly after inflation, when radiation dominated overwhelmingly, i.e.,
$$H =H_0 (z+1)^2 \sqrt{\Omega_r}$$
(Edit2: sorry I had this upside down originally, as well as wrong in a silly way)

Not sure if it is worth the effort in coding though...

 

[JimJCW]

I don't find z = 1000000 (1 million) to be special. It seems the calc time goes up exponentially with large z. Up to z = 300000 it seems to stay within 1 second execution time. This gives around 8 years after T = 0.

You are right; I mistakenly thought '99999' = '1000000 - 1'.

 

[pbuk]

http://jorrie.epizy.com/docs/index.html

I'm still struggling to get a working link out of my fork for direct use on github
I have marked it v8.3.x

A recap on links:

The stable version (currently 8.3.0, incorporating CSV download, $D_{hor}$ correction and the other changes we have discussed) is at https://light-cone-calc.github.io/.

@Jorrie your fork is at https://burtjordaan.github.io/light-cone-calc.github.io/, this serves whatever is in the docs folder of the main branch, which currently appears to be v.8.1.2 (although I think it is actually a bit modified from the "original" 8.1.2). But this code seems to be a bit behind what we are now working on (I think this was in the develop[ branch but that seems to have disappeared).

 

[JimJCW]

Calculator computation time:

The computation time of LightCone8 is discussed in Post #79-83, #86-88. For example, when the value of z is increased from 1 to 1000000, the computation time is increased from a fraction of a sec to 10 sec or so.

To get some ideas about this question, I did some experiments with the ICRAR calculator using PLANCK(2018+BAO) data and various values of z. The calculation times are all of the order of 1 sec. An example is given below:

@Jorrie, @pbuk

 

[Jorrie]

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.

 

[pbuk]

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.

 

[JimJCW]

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:

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

@Jorrie

 

[JimJCW]

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 = 10⁵⁰, but using LightCone8, it increases by a factor of 10 when z = 10⁶. 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

 

[Jorrie]

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 z_upper 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.

 

[pbuk]

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.

 

[JimJCW]

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​
z	300000	300000
Scale (a)	3.33332222E-06	3.33332222E-06
T Gyr	8.34828635E-09	8.34837088E-09
R Gpc	5.10964255E-09
Dnow Gpc	1.41602035E+01	1.41602035E+04
Dthen Gpc	4.72005209E-05	4.72005209E-02
DHor Gpc	5.10964255E-09
Dpar Gpc	5.12398784E-09
Vgen/c	2.89051673E+03
Vnow/c	3.19580877E+00
Vthen/c	9.23753872E+03
H(z)	5.86719042E+10	5.86719042E+10
Temp K	8.17646726E+05
rho kg/m3	6.46598880E-09	6.46643447E-09
OmegaM	1.11671814E-02	1.11671814E-02
OmegaL	9.16135695E-19	9.16135695E-19
OmegaR	9.88832819E-01	9.88832819E-01
OmegaT	1.000000000E+00	1.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

 

[Jorrie]

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 z_upper 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

 

[JimJCW]

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):

Please see Post #69.

 

[Jorrie]

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):

View attachment 313696

Please see Post #69.

It may just be a cashed issue, because for me it gives:

 

[JimJCW]

It may just be a cashed issue, . . .

You are right. It works for me too.