juliaastro / cosmology.jl Goto Github PK

Hello! I am a new Julia user, so this question may sound naive. I am using Julia v0.5 on Mac OSX 10.11.6 (15G1108), with the latest packages in Julia Astolibs.

I want to do calculate the luminosity distance considering both the errors from the redshift measurement and also the errors from the cosmology constants (taking Planck 2015 results: H_0=68.9± 0.1 and OmegaM=0.308± 0.012), using the Julia package Measurements.jl and this Cosmology.jl.

I tried the following:

julia> using Measurements

julia> using Cosmology

julia> c = cosmology(h=0.678± 0.009, OmegaM = 0.308± 0.012)
Cosmology.FlatLCDM{Measurements.Measurement{Float64}}(0.678 ± 0.009,0.6919090670178154 ± 0.012000000242838335,0.308 ± 0.012,9.093298218455683e-5 ± 2.4141499695015085e-6)

julia> luminosity_dist_mpc(c, 3.5651)
32007.785677876316 ± 573.8293114987347

It works. However, when I tried to include the error of the redshift, it gave errors:

julia> luminosity_dist_mpc(c, 3.5651 ± 0.0006)
ERROR: MethodError: Cannot `convert` an object of type Measurements.Measurement{Float64} to an object of type Float64
This may have arisen from a call to the constructor Float64(...),
since type constructors fall back to convert methods.
 in eignewt(::Array{Measurements.Measurement{Float64},1}, ::Int64, ::Int64) at ./quadgk.jl:275
 in kronrod(::Type{Measurements.Measurement{Float64}}, ::Int64) at ./quadgk.jl:383
 in do_quadgk(::Cosmology.##2#3{Cosmology.FlatLCDM{Measurements.Measurement{Float64}}}, ::Array{Measurements.Measurement{Float64},1}, ::Int64, ::Type{Measurements.Measurement{Float64}}, ::Measurements.Measurement{Float64}, ::Float64, ::Int64, ::Base.LinAlg.#vecnorm) at ./quadgk.jl:116
 in #quadgk#15(::Array{Any,1}, ::Function, ::Function, ::Measurements.Measurement{Float64}, ::Int64) at ./quadgk.jl:230
 in Z(::Cosmology.FlatLCDM{Measurements.Measurement{Float64}}, ::Measurements.Measurement{Float64}) at /Users/yangcht/.julia/v0.5/Cosmology/src/Cosmology.jl:144
 in luminosity_dist_mpc(::Cosmology.FlatLCDM{Measurements.Measurement{Float64}}, ::Measurements.Measurement{Float64}) at /Users/yangcht/.julia/v0.5/Cosmology/src/Cosmology.jl:162

Do you have any clue about this? Thank you!

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Cosmology 1.0.x should have [compat] allowing UnitfulAstro 1.0, right? The semver 1.0 would imply that things could break -- is that why it hasn't yet been done?

Dear all,

First, congratulations for the wonderful and well coded package!

May I make a small naive suggestion: that the parameters, for instance, h, Omega_m, Omega_r, etc be renamed to h_0, Omega_m0, Omega_r0. This is what they actually stand for (the values today) and, besides, in the future, it might be worth coding new functions which would provide the critical densities at an arbitrary time (or redshift).

Regards

Docstrings can be adapted from the README.md

The code makes use of several subtypes of AbstractCosmology for different cosmological models: (Closed|Flat|Open)LCDM and (Closed|Flat|Open)WCDM. However, it seems to me that are (if any) very little advantages in doing so, while there are possible disadvantages.

There are two main reasons to have different subtypes:

• The comoving_transverse_dist and comoving_volume functions are (slightly) different depending on the spatial curvature
• The function a2E can be (very slightly) simplified in case of a flat universe

On the other hand, in some cases one might want to store a cosmological model in a variable, and in that case one is essentially forced to use an abstract type, with the associated penalties in terms of efficiency. Such a situation, for example, arises in case one is interested in performing an inference on the cosmological parameters: in that case one would end up by having the associated cosmological model as an abstract type, which in turns would induce type instabilities in many associated parts of the code.

For this reason, I propose to consider the use of a structure that could accommodate closed, flat, and open cosmological models. In order to avoid making breaking changes, one could add new subtypes of AbstractCosmology:

abstract type AbstractGeneralCosmology <: AbstractCosmology end

struct GeneralLCDM{T <: Real} <: AbstractGeneralCosmology
    h::T
    Ω_k::T
    Ω_Λ::T
    Ω_m::T
    Ω_r::T
end

struct GeneralWCDM{T <: Real} <: AbstractGeneralCosmology
    h::T
    Ω_k::T
    Ω_Λ::T
    Ω_m::T
    Ω_r::T
    w0::T
    wa::T
end

It would then be trivial to write the relevant functions by just checking the signs of Ω_k in these fields. That would allow one to write type-stable code regardless of the value of the spatial curvature. Note that by just adding these two types one would not break existing code: so, in the usual case where one fixes the cosmological model, one would work with the current types. The general cosmology types could be returned by a specific function similar to cosmology (called, for example, general_cosmology or something similar).

In case there is consensus on this, I would be happy to contribute with the relevant code.

P.S. The other alternative could be to also remove the old (Closed|Flat|Open) types: that might break current code, in case one makes explicit reference to the cosmology type, but I guess that would be a minority of situations. Still, it is probably wiser not to make breaking changes...

Hello All,
I recently came across this package. I feel it can have more functions used in cosmology, such as a quick power spectrum calculator given the density fields. Do you think we can add new stuff to it? Is there an active effort in doing so?

Looks like master is updated to account for quadgk() moving from base to a package, but Metadata.jl hasn't been updated accordingly.

Just wondering if the default cosmology shouldn't be updated to the Planck '15 values?

Also, is there some way of passing a name of the result, similar to Astropy, which would set all defaults. Something along the lines of Cosmology(results="WMAP9") rather than having to set the values manually?

ref. https://discourse.julialang.org/t/how-to-use-units-in-cosmology-jl/51935/2, this package includes several examples in its documentation which require Unitful and UnitfulAstro to run. Those requirements should either be made clear in the documentation, or the relevant parts of Unitful/UnitfulAstro should be re-exported from here.

PackageEvaluator.jl is a script that runs nightly.
It attempts to load all Julia packages and run their tests (if available) on both the stable
version of Julia (0.3) and the nightly build of the unstable version (0.4).
The results of this script are used to generate a package listing
enhanced with testing results. This service also benefits package developers by notifying them if
their package breaks for some reason (caused by e.g. changes in Julia, changes in dependencies,
or broken binary dependencies.)

Currently PackageEvaluator attempts to find your test scripts using a heuristic, preferring the
standarized test/runtests.jl whenever present. Using test/runtests.jl allows people to test
your package using simply Pkg.test("Cosmology"), with any testing-only dependencies being
installed by looking at test/REQUIRE.

Your package doesn't appear to have a test/runtests.jl file. PackageEvaluator is going to move
away from auto-detecting tests and will instead only test packages with a test/runtests.jl
file. This change will take place in about a month.

You can:

• Add the file and tag a new version. You may in fact have already added this file but not
  tagged a new version. PackageEvaluator only tests your latest tagged verison, so you must tag
  for the file to be detected.
• Chose to do nothing. PackageEvaluator will stop attempting to test your package, and the testing
  status will be reported as "not possible".

If you'd like help or more information, please just reply to this issue.

julia> using Cosmology
[ Info: Precompiling Cosmology [76746363-e552-5dba-9a5a-cef6fa9cc5ab]
ERROR: LoadError: UndefVarError: Gyr not defined
Stacktrace:
 [1] top-level scope (repeats 2 times)
   @ none:1

Is there something related to Unitful missing in [76746363] Cosmology v1.0.0 that does not allow me to compile?
Thanks for the great work in putting this package together! Very useful and handy!