Adding power spectra and more to Cosmology.jl

32 views
Skip to first unread message

Kilian Walsh

unread,
Aug 30, 2016, 7:28:45 PM8/30/16
to Julia Astro
Hi all!

I've recently started learning julia and would love to contribute! I'd be interested in adding some more functionality to the Cosmology package. My work is in large scale structure so I plan to see if I can make some fast and flexible julia code that can compute power spectra, halo mass functions, and the like. My goal was to do this with a fork from Cosmology.jl and I thought I'd ask if there was any direction planned for this package or if there are some standard practices here when it comes to pull requests as I'd love to share anything I end up with. My coding background is in python, so I would be taking a lot of inspiration from packages like this one:

https://github.com/roban/CosmoloPy

Thanks,
Kilian

Kyle Barbary

unread,
Aug 30, 2016, 7:57:15 PM8/30/16
to julia...@googlegroups.com

Hi Kilian,

I’m not personally aware of any existing Julia tools for power spectra and halo mass functions; these sound like they’ll be great to have!

Practically, there’s a question of whether they should go in Cosmology.jl or in a separate package. Looking at what has been done in Python, the distance-related functionality in CosmoloPy was merged into astropy as astropy.cosmology in 2012, and development has continued there. I believe LSS specific functionality has been developed in external packages (such as halotools), though I don’t work in LSS so I’m not entirely sure about that. My gut feeling is to do the same here: keep Cosmology.jl roughly limited to the current scope and develop LSS tools in a separate package that depends on Cosmology.jl. This seems like a natural split, as some cosmologists need the distance functionality, but not LSS functionality.

In terms of plans for Cosmology.jl I have some idea for refactoring the internals in order to expose type-stable functions for specific cosmologies in the public interface: The cosmology() function is not currently type stable, which could be a problem when performing optimization or sampling of cosmological parameters. For these cases, it would be useful to be able to specify that you want, e.g., a FlatLCDM cosmology. The idea of refactoring would be to expose these types (while maintaining the behavior of the current cosmology() function).

Best,
— Kyle

Reply all
Reply to author
Forward
0 new messages