I LightCone Calculator Improvements

[Jorrie]

Cool! - it looks like we've got ourselves a workable calculator.
I have just pushed a small update that shows $\Omega_M$ and $\Omega_R$ on the conversion side, as discussed before.

 

[JimJCW]

Discrepancy between LightCone8 and LightCone7:

When comparing the outputs of LightCone8 and LightCone7, I noticed a discrepancy in calculated event horizon:

I think the value calculated with LightCone8 is questionable.

@Jorrie, @pbuk

 

[pbuk]

I think the value calculated with LightCone8 is questionable

It seems to be exactly the same as R, I'll have a look tonight (UK).

 

[pbuk]

Discrepancy between LightCone8 and LightCone7:

When comparing the outputs of LightCone8 and LightCone7, I noticed a discrepancy in calculated event horizon:

Interesting, I had started with the code from the last version of LightCone7 http://jorrie.epizy.com/lightcone7/2022-05-14/LightCone7.html and it gives exactly the same incorrect results. But when I use an older version of LightCone7 e.g. http://jorrie.epizy.com/Lightcone7-2021-03-12/LightCone_Ho7.html I get the expected results.

I have now added the correct calculation in the back end development branch, I will push this to the live site over the weekend along with the new UI.

 

[Jorrie]

Interesting, I had started with the code from the last version of LightCone7 http://jorrie.epizy.com/lightcone7/2022-05-14/LightCone7.html and it gives exactly the same incorrect results. But when I use an older version of LightCone7 e.g. http://jorrie.epizy.com/Lightcone7-2021-03-12/LightCone_Ho7.html I get the expected results.

No idea how that happened, accept that lots of experimentation happened around that time.
Anyway, thanks for the excellent work done by JimJCW and yourself.

 

[Jorrie]

No idea how that happened, accept that lots of experimentation happened around that time.

@pbuk It happens in line 47 of your new calculate.js, where the mapping for Dhor is incorrect. Note Y (legacy) is the same as R later.
44 Y: entry.r,
---
47 Dhor: entry.r,

 

[pbuk]

@pbuk It happens in line 47 of your new calculate.js, where the mapping for Dhor is incorrect. Note Y (legacy) is the same as R later.
44 Y: entry.r,
---
47 Dhor: entry.r,

Yes, I picked this up from line 267 of the 2022-05-14 version of LightCone7

          if (Dhor < Y)
              Dhor = Y ;

I removed the test because Dhor was never being set above 0 anywhere else in the code so was always being set to Y (r). This was because the line

          Dhor =  a * (Dte-Dc);

which was there in LightCone7 2021-03-12 disappeared in the later version.

 

[Jorrie]

Yes, correct. Is it something that you can fix on the calculate side, or must I fix it outside of calculate?

 

[JimJCW]

Interesting, I had started with the code from the last version of LightCone7 http://jorrie.epizy.com/lightcone7/2022-05-14/LightCone7.html and it gives exactly the same incorrect results. But when I use an older version of LightCone7 e.g. http://jorrie.epizy.com/Lightcone7-2021-03-12/LightCone_Ho7.html I get the expected results.

Let’s call
A: http://jorrie.epizy.com/Lightcone7-2021-03-12/LightCone_Ho7.html
B: http://jorrie.epizy.com/lightcone7/2022-05-14/LightCone7.html
and use PLANCK Data (2015) for the present discussion.

Result from A:

Result from B:

Note that Ro and Dhor overlap with each other.Comparing the Calculation.js files of A and B, I noticed that some statements in A are not in B: near Line 180 and Line 245. If we put the missing statements back to B:

pa = a_ic * sf;
////////////////*************Add the following missing line
a = a_ic + (pa / 2);
////////////////*************Found the problem
qa = Math.sqrt((Om / a) + Ok + (Or / (a * a)) + (Ol * a * a));
Dthen = 0;
}
////////////////*************Add the following missing lines
else
{
Dnow = Math.abs(Dtc-Dc);
Dthen = a * Dnow;
}
Dhor = a * (Dte-Dc);
////////////////*************
Dpar = a * Dc;

the modified B gives the following result:

@Jorrie

 

[pbuk]

Yes, correct. Is it something that you can fix on the calculate side, or must I fix it outside of calculate?

Fixed now. I've also tidied up the html (there were some extra empty <td>s and unmatched </tr>s) and bumped the version to 8.3 for the added CSV functionality.

I've pulled all these changes into the 'main' branch and changed the source for the live site back to 'main' from 'develop' for good practice.

 

[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