Another suggestion, if I may – catalog matching.
In astropy: Separations, Offsets, Catalog Matching, and Related Functionality — Astropy v7.0.1.
In Julia: FlexiJoins.jl supports joining catalogs of sky coordinates, playing nicely with SkyCoords.jl. Works with UncertainSkyCoords.jl as well, for more complex coordinate matching criteria.
3 Likes
Btw, I wonder if
carries any practical implications?
Those packages have different developers, and I don’t think there’s any universal coordination – and idk if explicit coordination is needed at all…
I don’t know. I haven’t used SkyCoords.jl. This is a question for the author of SkyCoords.jl.
There is no universal coordination; for various reasons.
I am open for discussion on what would be the best comparaison to astropy.tables. One of the things that i was unsure when is was putting DataFrames.jl in there was about Metadata, astropy.tables support metadata for both the whole table and individual columns. Granted i do not know if I can do that with Dataframes.jl, but that had me thinking abit already.
Sattelite toolbox will be added to the masterlist
As now pointed out by @barrettp there is no coordination. So i am debating wheter to remove this mention. My argument for including this was not mainly for the coordination but for the ease of finding. As we have the JuliaAstro website (Home · JuliaAstro) aswell as the Github Organisation (Julia Astro · GitHub). In my opinion this will likely be the first point of contact for people using Julia for Astronomy similar to Astropy and their Affiliated Packages who are just the first point people will turn to.
Coordination among package developers doesn’t seem crucial (though maybe helpful), rather the important thing (as was mentioned) is having the python → Julia guide and some nice examples/tutorials on how things fit together, especially for packages outside of JuliaAstro. If someone downloads a CSV of astronomical objects and wants to work with it, how is that done? etc.
1 Like
Constants (
astropy.constants) ⟹ UnitfulAstro.jl , Unitful.jl
I would also add PhysicalConstants.jl here as it provides access to many constants of interest as well.
2 Likes
As a guide to improving it, the Rust core developers came up with several problematic use cases of async. It has helped them to close some gaps of usability of Rust async.
I wonder if something similar could be useful for JuliaAstro: describe various workflows and see if there is anything that is currently impossible or difficult to do with the current packages.
On the topic of real-life examples – I recently created GitHub - aplavin/astroplots.jl and started filling it with code to reproduce some figures/analyses from my papers. Not 100% of papers/figures, but that’s a start.
The code is shared in the form of commented Pluto notebooks. Comments should make it useful not just for running as-is, but also for learning.
Those notebooks are fully self-contained. Everything from (down)loading the data to the final figure.
There’s already some backlog, but I aim to keep the repo regularly expanded, and maybe even put these code links to my papers themselves.
The action to go from ad-hoc wip code to a reasonably clean script/notebook takes quite some effort, but I find it generally useful for myself 
5 Likes
The primary reason for coordination is funding and resources. That is the reason that Astropy is successful. They are able to coordinate their activities and, as a result, get funding to pay for developers to continue develop software and to support their users. AstroJulia has none of this, although we have tried and will continue to do so. It is not a technical issue. Julia is technically much better than Python. It is a cultural issue, and coordination is a critical piece of that cultural issue.
5 Likes
Not sure if it qualifies, but CellListMap.jl has been used to compute statistics of astronomical objects, something that in python is covered (as a special case), by the halotools package. Performance wise, last time I checked, CellListMap.jl was faster, and with the advantage of allowing fully custom statistics to be implemented efficiently.
2 Likes
Since they haven’t been mentioned yet, I want to also point out:
- SPICE for Julia access to NASA’s SPICE toolkit
- EasyFITS for FITS file handling
- OIFITS and OITOOLS for working with optical interferometry data
2 Likes
Yeah, that’s a good point. I was at this past year’s Winter AAS meeting, and IIRC there was at least one (if not more) “poster” about astropy. And someone else had one showing a Jupyter notebook for calculating Hubble point-spread functions. Something like that for a Julia application would be pretty good advertising, but then its back to the funding issue…
This is perhaps related to the topic and at least of interest:
2 Likes
Seeing all the community support here is so dope. If it’s cool with other folks, I updated our JuliaAstro site to start including the package suggestions mentioned in this thread
3 Likes
The next JuliaAstro Meeting is scheduled for Wednesday, April 30, 16:00 UTC (17:00 BST, 12:00 EDT, 09:00 PDT). Hope to see you there.
Here is the Zoom link: Launch Meeting - Zoom
2 Likes
I am not hundred percent sure whether to add this to the master list. Do I understand this correctly that its basically just a part of what Halotools does? Maybe more general?
Oh I really love this. Great for implementing that this quickly
1 Like
Neither am I. I’m not from the astro-field. CellListMap.jl is used in this context as a tool to compute neighborlists, explicitly or not (as NearestNeighbors.jl can be used, with different tradeoffs). These are used for particle-simulation data analysis, and as such are useful for astrophysical research. The halotools package includes a routine to compute neighborlists with the same purpose, and the corresponding astro-data-analysis functions written on top of that.