A glitch in Jorrie’s Cosmo-Calculator?

  • Context: Undergrad 
  • Thread starter Thread starter JimJCW
  • Start date Start date
Click For Summary

Discussion Overview

The discussion revolves around potential inconsistencies in Jorrie’s Cosmo-Calculator, particularly when comparing results from the calculator based on the ΛCDM model with those from Gnedin’s and Wright’s calculators. Participants explore the nature of these discrepancies, possible glitches, and the underlying calculations involved.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • Some participants note that Jorrie’s calculator produces results that are consistently inconsistent with those from Gnedin’s and Wright’s calculators, especially for small redshift values.
  • There are suggestions that the discrepancies may stem from issues with numerical integration, with one participant proposing that a fixed delta-z might be causing the peculiar results.
  • Some participants emphasize the importance of understanding the underlying calculations to identify discrepancies, suggesting that users should be able to perform their own calculations.
  • One participant mentions that the calculator was intended more as an educational tool rather than a professional-grade tool, which may contribute to the observed inconsistencies.
  • There are discussions about specific lines of code in the calculator that may be contributing to the discrepancies, with suggestions for modifications to improve accuracy.
  • Participants discuss the effect of changing parameters in the calculation process, noting that while adjustments can reduce discrepancies, they do not completely eliminate them.
  • Some participants express curiosity about the problem and suggest that further investigation is needed to fully understand the issues at hand.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the existence of a glitch in Jorrie’s calculator, as multiple competing views and hypotheses about the source of discrepancies remain. There is ongoing exploration of potential fixes and improvements, but no definitive agreement on the nature of the problem.

Contextual Notes

Limitations include unresolved mathematical steps related to the numerical integration and the specific implementation details of the calculator's algorithms. The discussion also highlights the dependence on the definitions and parameters used in the calculations.

  • #151
Let’s summarize the situation:

(1) The glitch associated with Dnow(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 Dnow(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.
 
Space news on Phys.org
  • #152
JimJCW said:
(3) The difference in calculated Dnow(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.
 
Last edited:
  • #153
Jorrie said:
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
z0.020.02
Scale (a)9.803921569E-019.803921569E-01
H(z)6.837765717E+016.837765717E+01
OmegaM3.217304253E-013.217304253E-01
OmegaL6.781722253E-016.781722253E-01
OmegaR9.734946123E-059.734946125E-05
OmegaT1.000000000E+001.000000000E+00

but not for Dnow and Dthen:

LightCone8ICRAR
z0.020.02
T Gyr1.351246087E+011.351276116E+01
Dnow Gpc8.808897954E-028.810076113E+01
Dthen Gpc8.636174465E-028.637329523E+01
rho kg/m38.782193743E-278.782799071E-27

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

Similar threads

  • · Replies 15 ·
Replies
15
Views
2K
  • · Replies 100 ·
4
Replies
100
Views
7K
  • · Replies 19 ·
Replies
19
Views
4K
  • · Replies 18 ·
Replies
18
Views
2K
  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 17 ·
Replies
17
Views
3K
  • · Replies 20 ·
Replies
20
Views
2K
  • · Replies 0 ·
Replies
0
Views
4K
  • · Replies 8 ·
Replies
8
Views
4K
  • · Replies 0 ·
Replies
0
Views
3K