search

halomod / TheHaloMod-SPA

Single-page app for TheHaloMod
https://www.thehalomod.app/
MIT License
4 stars 0 forks source link

feature request: default hires transfers for the default cosmologies #79

Open steven-murray opened 3 years ago

steven-murray commented 3 years ago

There are a few options for default cosmologies (Planck18, PLanck15, etc.). Since a lot of people will be choosing these defaults, it makes sense to have pre-computed hi-res transfer functions from CAMB sitting in files to be read (running CAMB is the slowest part of the calculation).

aneuhold commented 3 years ago

@steven-murray not entirely sure what this means. Can you dumb it down a bit? Was just working with the cosmological constants portion in #76 , so have that fresh in the memory right now. Might be able to implement this quickly.

steven-murray commented 3 years ago

So, this has to do with the option "CAMB" from the Transfer tab (CAMB is one of the options for the transfer_model). CAMB is an external fortran program that gets called to do really detailed cosmological calculations, and pretty much everything else that hmf/halomod computes is based on that transfer function. It is also the most time-consuming calculation.

Now, at the moment, what should probably happen is that either (1) there is a default pre-computed full TracerHaloModel object on disk that is read to initialize any session, in which case that transfer function computation doesn't need to be done, at least right at the start. Or (2) the default transfer_model should be EH, which is much faster (since it's more approximate).

But we could have almost the best of both worlds if we used CAMB as default, but were able to pre-compute some of the most common transfer functions (the transfer function really just depends on the cosmo parameters, so we'd need one transfer function for each set of cosmo params). We could store these as ASCII files, and use the FromFile transfer model to read them if the parameters matched up. Obviously, if the user manually changed any of the cosmo params away from the default sets, then it would have to actually do the computation, but that's probably OK.

aneuhold commented 3 years ago

Ahhhh. Okay yes, this is more complicated than I initially thought, but it is making more sense now. We can make a user story out of this. It might not be implemented until the next sprint though, because from the sounds of it, it will need quite a bit of infrastructure work to accomplish it. Some of the work with the generic forms should help with this though, meaning it will be easier to implement next sprint than if we were to try now. I think you have mentioned this before. It is very nice to have it in writing.

steven-murray commented 3 years ago

Yup, no rush!

steven-murray commented 3 years ago

I think this should be scrapped in favour of including these directly in hmf.