juliaastro / cosmology.jl Goto Github PK
View Code? Open in Web Editor NEWCosmology library for Julia
Home Page: https://juliaastro.github.io/Cosmology.jl/dev
License: MIT License
Cosmology library for Julia
Home Page: https://juliaastro.github.io/Cosmology.jl/dev
License: MIT License
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.
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!
Looks like master is updated to account for quadgk() moving from base to a package, but Metadata.jl hasn't been updated accordingly.
Docstrings can be adapted from the README.md
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
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?
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:
If you'd like help or more information, please just reply to this issue.
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!
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:
comoving_transverse_dist
and comoving_volume
functions are (slightly) different depending on the spatial curvaturea2E
can be (very slightly) simplified in case of a flat universeOn 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?
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.