A glitch in Jorrie’s Cosmo-Calculator?

[JimJCW]

Some observations:

(1) The suggested correction to LightCone7 discussed in Post #136,

where, (s_eq = z_eq), is consistent with the following statements in LightCone8:

(2) It is noticed that whenever z_lower in LightCone8 is set to be 0, there is extra line printed. For example,

This is a little bit strange, but inconsequential.

@Jorrie, @pbuk

 

[pbuk]

Yes it is annoying: it is a consequence of ensuring that ranges spanning z = 0 always include z = 0 exactly (otherwise lines which are not smooth there look wrong). I'll add it to the bottom of the list

 

[JimJCW]

Yes it is annoying: it is a consequence of ensuring that ranges spanning z = 0 always include z = 0 exactly (otherwise lines which are not smooth there look wrong). I'll add it to the bottom of the list

I am sorry if I was a little pushy. I misunderstood your writing in Post #133:

“I think I'm all done now, . . .”​

 

[Jorrie]

Yes it is annoying: it is a consequence of ensuring that ranges spanning z = 0 always include z = 0 exactly (otherwise lines which are not smooth there look wrong). I'll add it to the bottom of the list

I have looked at all the code, tested as far as I could and I am very happy with it. Your model.ts code is a little outside of my capabilities as a coder, so I cannot really assist with the doubling of the z=0 line issue.

I'm happy to look after the UI and the Tutorial, so if anyone has any suggestion, we can discuss and implement if approved by the core team. The equations in Tutorial part III still represent the LCDM model accurately. Do you think we must put more in there to indicate how you have implemented the model?

 

[JimJCW]

Hi @pbuk and @Jorrie,

I am getting some puzzling results concerning output of LightCone8. Let’s use PLANCK 2015 Data and calculate OmegaM and OmegaR with three different methods:

1. LightCone8
2. Correct equations,

3. Wrong equations,

omegaM0 = (1 - OmegaL0) * zEq / (zEq + 1)​

omegaR0 = OmegaM0 / zEq​

The results are shown in the table below:

Is it possible that the LightCone8 result is calculated with the wrong equations?

 

[pbuk]

Is it possible that the LightCone8 result is calculated with the wrong equations?

No, I have looked into it and it is more subtle than that. The problem is that LightCone8 uses the same mapping to the UI as LightCone7 which does not pass the input value of $\Omega_\Lambda$ directly to the caculations, it actually passes
$$ \left ( \frac{\frac{978}{H_0}}{\frac{978}{H_0\sqrt{\Omega_\Lambda}}} \right )^2 !$$
This obviously introduces roundoff error, and because of the sqaring with a 53 bit mantissa I'd expect only about 8 decimal digits of accuracy - your calculation shows ~7.5. The fact that a similar result occurs when taking $z_{eq}$ instead of $s_{eq}$ is coincidence.

I can easily fix this by changing the inputs to the back-end to read directly from the input fields.

 

[pbuk]

I can easily fix this by changing the inputs to the back-end to read directly from the input fields.

Well I did that, which was very worthwhile but it didn't fix the problem, which was actually less subtle: the input field that is labelled $z_{eq}$ was actually

<input name="s_eq" />

so while it looked as though the conversion $s_{eq} = z_{eq} + 1$ had been done, it never was!

I have now fixed this, and tidied up the credits and a couple of other things, enjoy.

 

[JimJCW]

Well I did that, which was very worthwhile but it didn't fix the problem, which was actually less subtle: the input field that is labelled $z_{eq}$ was actually

<input name="s_eq" />

so while it looked as though the conversion $s_{eq} = z_{eq} + 1$ had been done, it never was!

I have now fixed this, and tidied up the credits and a couple of other things, enjoy.

Great! Now we have,

	z​	OmegaM​	OmegaL​	OmegaR​	OmegaT​
LightCone8	0​	0.3089083630000​	0.691​	0.0000916370107​	1​
Wrong Eqs	0​	0.3089083358054​	0.691​	0.0000916641946​	1​
Correct Eqs	0​	0.3089083629893​	0.691​	0.0000916370107​	1​

 

[pbuk]

Thanks, of course the UI only displays a maximum 9 digits, the results at full precision are:

• OmegaMatterT: 0.3089083629893239
• OmegaLambdaT: 0.691
• OmegaRadiationT: 0.0000916370106761566
• OmegaTotalT: 1

A useful feature for the UI would be display and/or download in CSV and/or JSON format of the full precision results.

 

[Jorrie]

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 digit, with $H_0$ the main constraint. A more important UI change would be to have the latest (2018/2021) Planck data release as an option.

Also, historically, LightCone has 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$ 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 $\Omega_\Lambda$, the latter becoming a derived parameter.

Before we change the mapping between the UI and the calculation module, I think we should decide on this.

BTW, since the "glitch" has now been fixed, I think we should start a new thread on LightCone Improvement and close this one.

 

[JimJCW]

Let’s summarize the situation:

(1) The glitch associated with D_now(z) discussed in Post #1 is eliminated in LightCone8 (see Post #102).

(2) The error associated with Ω’s in Jorrie’s calculator discussed in Post #109 is fixed in LightCone8 (see Post #148).

(3) The difference in calculated D_now(z) using LightCone8 and ICRAR still needs to be resolved (see Post #102). I believe I can do that, but first, I need @pbuk and @Jorrie to change the following conversion,

1 pc = 3.262 ly​

in LightCone8 to,

1 pc = 3.261563777 ly​

This will make direct comparison of results from the two calculators possible.

 

[Jorrie]

(3) The difference in calculated D_now(z) using LightCone8 and ICRAR still needs to be resolved (see Post #102). I believe I can do that, but first, I need @pbuk and @Jorrie to change the following conversion,

1 pc = 3.262 ly​

in LightCone8 to,

1 pc = 3.261563777 ly​

This will make direct comparison of results from the two calculators possible.

This could surely improve accuracy for comparison purposes, but take note that Lightcone8 does not allow $\Omega_r$ to be identically zero, but only a minimum value through setting $z_{eq} = 999999$.

(This with reference to your Post #102, where you compared calculators for $\Omega_r = 0$)

At low redshift a tiny radiation density makes negligible difference, but not so for high redshift work.

 

[JimJCW]

This could surely improve accuracy for comparison purposes, . . .

My goal is to be able to say,

Calculation results from Lightcone8 and ICRAR are consistent.​

This is true for the following quantities,

	LightCone8​	ICRAR​
z	0.02	0.02
Scale (a)	9.803921569E-01	9.803921569E-01
H(z)	6.837765717E+01	6.837765717E+01
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

but not for D_now and D_then:

	LightCone8	ICRAR
z	0.02	0.02
T Gyr	1.351246087E+01	1.351276116E+01
Dnow Gpc	8.808897954E-02	8.810076113E+01
Dthen Gpc	8.636174465E-02	8.637329523E+01
rho kg/m3	8.782193743E-27	8.782799071E-27

I believe changing the conversion to ‘1 pc = 3.261563777 ly’ in LightCone8 will resolve this discrepancy.
@pbuk