juliaastro / skycoords.jl

Astronomical coordinate systems in Julia

SkyCoords.jl

Basic astronomical coordinate systems in Julia.

Installation

julia> Pkg.add("SkyCoords")

Usage

There are currently three supported coordinate systems. The following immutable types are used to represent coordinates in each system:

• ICRSCoords: ICRS coordinates system
• GalCoords: Galactic coordinates system
• FK5Coords: FK5 coordinates system (with arbitrary equinox)
• EclipticCoords: Ecliptic coordinates system

julia> c1 = ICRSCoords(0, 0)  # inputs are ra, dec in radians
ICRSCoords{Float64}(0.0, 0.0)

julia> c2 = convert(GalCoords, c1) # convert to a different system
GalCoords{Float64}(1.6814027872278692, -1.0504884034813007)

julia> convert(FK5Coords{2000}, c1)
FK5Coords{2000,Float64}(1.1102233723050067e-7, 4.411803426976326e-8)

julia> separation(c1, ICRSCoords(1., 0.)) # radians
1.0

julia> position_angle(c1, ICRSCoords(1, 0)) |> rad2deg
90.0

For more information, visit the documentation

License and Credits

License is MIT. This package profits from the hard work that went into astropy.coordinates, especially in terms of testing and coordinate system definitions.

skycoords.jl's Issues

New Type for Utility

I'm curious of the thoughts of creating a type along the lines of CartCoords, UnitCoords, CartesianCoords, etc. that serves as the unit-sphere implementation of the coordinates.

This is already used in the code a bit, via coords2cart and cart2coords. My theory is that we can create some <:AbstractSkyCoords type that serves as the base, default representation of all SkyCoords. this means as long as we provide a conversion to this type for each new type, we could allow efficient code reuse using a pretty Julian style of generics with fallbacks and separate optimized code.

This, itself, was part of my features list #30 but i'm starting to see how we can use it to better serve our package in terms of functionality, not just extra features.

Convert from local coordinates to non-local

Hi, there! I would need to convert from (local) horizontal coordinates (Altitude, Azimuth) to non-local coordinates, such as ICRSCoords, given a Julian Date and the exact location on the Earth. Is it currently possible?

Error tagging new release

The URL of this package does not match that stored in METADATA.jl.
cc: @kbarbary

Feature Requests

Here are some features I'd love to see here:

• get the position angle between two coordinates
• Unitful.jl integration (this may require some restructuring of the core SkyCoords type
• Given a separation and position angle, calculate a skycoord from another
  • EG c1 = ICRSCoord(0, 0); c2 = offset(c1, sep, theta)
• FK4Coord (#8)
• EclipticCoord (#8)
• AltAzCoord (or maybe HorizontalCoord)
• CartesianCoord (x, y, z, requires a known distance or can normalize to unit distance)
• String representation of coordinates
  • astropy does this really nicely, you specify a format string like "hmsdms" to get "hr min s, deg arcm arcs" just like simbad would show
• some more utilities for converting between hour angles, degrees, and radians

I'm happy to crack open some of these but some of these implementations would make good first issues for possible contributors.

Support for other AbstractFloat types

Is there any plan to support AbstractFloat types for sky coordinates? I'd like to use this package in AstroLib, which doesn't prefer any floating point type, instead SkyCoords uses Float64 everywhere.

Not Installing on Julia 1.1

Whenever I run

using Pkg
Pkg.add("SkyCoords")

I get the following

Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
Unsatisfiable requirements detected for package SkyCoords [fc659fc5]:
 SkyCoords [fc659fc5] log:
 ├─possible versions are: [0.1.0-0.1.1, 0.2.0] or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions [0.1.0-0.1.1, 0.2.0]
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

Stacktrace:
 [1] #propagate_constraints!#61(::Bool, ::Function, ::Pkg.GraphType.Graph, ::Set{Int64}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:1005
 [2] propagate_constraints! at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:946 [inlined]
 [3] #simplify_graph!#121(::Bool, ::Function, ::Pkg.GraphType.Graph, ::Set{Int64}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:1460
 [4] simplify_graph! at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:1460 [inlined] (repeats 2 times)
 [5] resolve_versions!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}, ::Nothing) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:371
 [6] resolve_versions! at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:315 [inlined]
 [7] #add_or_develop#63(::Array{Base.UUID,1}, ::Symbol, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:1171
 [8] #add_or_develop at ./none:0 [inlined]
 [9] #add_or_develop#15(::Symbol, ::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:54
 [10] #add_or_develop at ./none:0 [inlined]
 [11] #add_or_develop#14 at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:31 [inlined]
 [12] #add_or_develop at ./none:0 [inlined]Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
Unsatisfiable requirements detected for package SkyCoords [fc659fc5]:
 SkyCoords [fc659fc5] log:
 ├─possible versions are: [0.1.0-0.1.1, 0.2.0] or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions [0.1.0-0.1.1, 0.2.0]
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

Stacktrace:
 [1] #propagate_constraints!#61(::Bool, ::Function, ::Pkg.GraphType.Graph, ::Set{Int64}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:1005
 [2] propagate_constraints! at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:946 [inlined]
 [3] #simplify_graph!#121(::Bool, ::Function, ::Pkg.GraphType.Graph, ::Set{Int64}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:1460
 [4] simplify_graph! at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/GraphType.jl:1460 [inlined] (repeats 2 times)
 [5] resolve_versions!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}, ::Nothing) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:371
 [6] resolve_versions! at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:315 [inlined]
 [7] #add_or_develop#63(::Array{Base.UUID,1}, ::Symbol, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:1171
 [8] #add_or_develop at ./none:0 [inlined]
 [9] #add_or_develop#15(::Symbol, ::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:54
 [10] #add_or_develop at ./none:0 [inlined]
 [11] #add_or_develop#14 at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:31 [inlined]
 [12] #add_or_develop at ./none:0 [inlined]
 [13] #add_or_develop#13 at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:29 [inlined]
 [14] #add_or_develop at ./none:0 [inlined]
 [15] #add_or_develop#12(::Base.Iterators.Pairs{Symbol,Symbol,Tuple{Symbol},NamedTuple{(:mode,),Tuple{Symbol}}}, ::Function, ::String) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:28
 [16] #add_or_develop at ./none:0 [inlined]
 [17] #add#20 at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:59 [inlined]
 [18] add(::String) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:59
 [19] top-level scope at In[1]:2
 [13] #add_or_develop#13 at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:29 [inlined]
 [14] #add_or_develop at ./none:0 [inlined]
 [15] #add_or_develop#12(::Base.Iterators.Pairs{Symbol,Symbol,Tuple{Symbol},NamedTuple{(:mode,),Tuple{Symbol}}}, ::Function, ::String) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:28
 [16] #add_or_develop at ./none:0 [inlined]
 [17] #add#20 at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:59 [inlined]
 [18] add(::String) at /build/julia/src/julia-1.1.0/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:59
 [19] top-level scope at In[1]:2

I've taken a look at the Compat.toml and it has the following contents

["0.1"]
Compat = "0.0-1.5"
julia = "0.3-0.7"

["0.2"]
Compat = "0.41-1.5"
StaticArrays = "0.3.1-0.10"
julia = "0.6-0.7"

I think the cap at 0.7 is the culprit. I see that there is no cap in the REQUIRE file but maybe a nudge to the repo will trigger a new METADATA sync.

Enabling multi-threading?

These days I'm pushing a few changes to slightly improve performance of the conversions, and others will come in the next days ;-)

In addition, there is a one-line change that can boost performance: enabling multi-threading

diff --git a/src/SkyCoords.jl b/src/SkyCoords.jl
index 5aa77d2..a092321 100644
--- a/src/SkyCoords.jl
+++ b/src/SkyCoords.jl
@@ -258,7 +258,7 @@ function convert{T<:AbstractSkyCoords, n, S<:AbstractSkyCoords}(
     ::Type{Array{T,n}}, c::Array{S, n})
     m = Matrix33{_eltype(S)}(rotmat(T, S))
     result = similar(c, T)
-    for i in 1:length(c)
+    Threads.@threads for i in 1:length(c)
         r = m * coords2cart(c[i])
         lon, lat = cart2coords(r)
         result[i] = T(lon, lat)

Running the benchmark script at https://github.com/kbarbary/SkyCoords.jl/pull/9#issuecomment-336395556 I get this new plot by using 4 threads:

With 1 million coordinates SkyCoords.jl is still one order of magnitude faster than Astropy :-) The change was applied on top of current master, so there is still room for some minor improvement.

The problem of multi-threading in Julia is that it's still experimental. However, when running Julia with just one thread there is zero overhead and no issues. Thus, the change I propose should be safe enough (doesn't break single-thread systems) and we would only need to warn people that multi-threading may not work.

Add Ecliptic and FK4 coordinates

@TestSubjector ported euler function from IDL AstroLib to AstroLib.jl. It can be used to convert between different coordinates, including ecliptic and FK4, missing in SkyCoords.jl. These coordinates should be integrated in this package.

Insertion of coordinates in degree or hours

Currently, coordinates can be inserted only in radians. What about using an external package which defines physical units in order to allow users to insert coordinates in degree or hours?

If this idea looks good, I'd suggest using Unitful.jl, which has both a simple interface a good performance. Last time I checked it, SIUnits.jl had not so good performance

Pkg registration

I am new to julia, and thus necessarily new to SkyCoords and this entire package ecosystem, so I apologize if this is not the right place for this report. I found ICRSCoords and separation() here, which seemed to be a perfect fit for some of my julia-noob exercises. But when I did Pkg.add("SkyCoords"), I received a version that was missing separation() entirely. Re-installing via Pkg.clone(...) gave me all the goods. Is it possible to update the registration / cut a release / whatever it takes to get this functionality into the default distribution pipeline?

Add AltAzCoord

To follow https://docs.astropy.org/en/stable/api/astropy.coordinates.AltAz.html

I'm currently tackling this, so PR inbound soon. I wanted to open an issue to start having discussions on this.

There are a ton of steps between local coordinates and the others. Astropy has only a few conversions fixed and uses a graph to find the shortest path between different coordinate systems. Should we do this as well? That would require a rewrite of the conversion methods. Additionally, as I'm getting into the weeds now reading how the conversions work, astropy uses calls to erfa for all the fast stuff. Is there a reason we shouldn't use the ERFA.jl wrapper? Or should we try a "pure julia" approach?

TagBot trigger 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!