BUGs: Inconsistencies with `Distance`

Signed-off-by: Nathaniel Starkman (@nstarman) [e-mail]

Round-tripping

1. The redshift is not actually stored, even if passed to the Distance constructor. This means the distance is recomputed every time and only to the accuracy of z_at_value. While this accuracy is high enough for actual astronomy purposes, the following fails:

>>> from astropy.coordinates import Distance
>>> from astropy.cosmology import Planck18
>>> d = Distance(z=100, cosmology=Planck18)
>>> d.z == 100
False

1. For large redshifts the default values of zmin and zmax mean the redshift cannot even be computed.

>>> from astropy.coordinates import Distance
>>> from astropy.cosmology import Planck18
>>> d = Distance(z=4e3, cosmology=Planck18)
>>> d.z
CosmologyError: Best guess z=999.9999999676769 is very close to the upper z limit 1000.
Try re-running with a different zmax.

Inconsistent cosmology

Distance doesn’t store the cosmology when initialized with a redshift, even if that cosmology is explicitly passed as an argument.

Consider the following:

>>> import astropy.coordinates as coord
>>> import astropy.cosmology as cosmology
>>> d = coord.Distance(z=100, cosmology=cosmology.Planck18)
>>> cosmology.default_cosmology.set("WMAP7")
>>> d.z
98.78242384189551

I think that if Distance is initialized with a redshift, that it should be tied to the cosmology, especially if the cosmology is also passed as an argument. This can be solved by storing the cosmology used at initialization (if initialized by z).

Conceptual

I think there might be a deeper conceptual problem. Calculating cosmological redshifts on distances smaller than 0.01 are pretty much meaningless because we are locally disconnected from the Hubble flow. Conversely, parallax measures on scales larger than 0.01 have and probably will never be observed. 1 AU is just too small a baseline. While it’s nice to have 1 class that does all distance measures, it doesn’t make much as much sense physically given the difference in applicable scales.

Possible Solution

My thought is that there should be a new class: CosmologicalDistance, with .value as the redshift. The physical distance would be accessible by some attribute, kind of the opposite of Distance. Now Distance.z would return a CosmologicalDistance. When Distance is initialized with a redshift it internally stores a CosmologicalDistance that also keeps the cosmology. Keeping the CosmologicalDistance synced to the retaining Distance would be a bit tricky, but not insurmountable. The CosmologicalDistance can have other nice attributes, like comoving_distance, since it stores the cosmology. Additionally, like SpectralQuantity (#10263), CosmologicalDistance can have (and provide) equivalencies like with_H0 and from https://github.com/astropy/astropy/pull/10143 (when merged)

System Details

macOS-10.16-x86_64-i386-64bit Python 3.8.2 | packaged by conda-forge | (default, Apr 24 2020, 07:56:27) [Clang 9.0.1 ] Numpy 1.18.4 astropy 4.3.dev1549+g7fa7ed275.d20210519 Scipy 1.4.1 Matplotlib 3.4.1

[mhvk]

Distance is used only if the unit is a length, so it would be safe from that perspective.

[mhvk]

I guess in the initializer one can raise an exception on redshifts that are out of range? And otherwise just document that the code always converts to length units? I’m not sure going beyond that is worth the effort for Distance (I can see the point in a new cosmology-specific class).