Different transfer_functions and matter_power_spectrum

[alexander-mead]

When I generate a cosmology object I have the option to specify a transfer_function and a matter_power_spectrum. I could not find an explanation of the difference between these two things in either the README, Doxygen docs or the pdf note that can be generated (000-ccl_note.pdf).

When specifying a cosmological model I can understand that one needs to specify a means of generating the linear power spectrum, and possibly a non-linear power spectrum, but I'm not sure how the transfer_function or matter_power_spectrum attributes of the cosmology structure map onto this.

It was also not clear to me what to make of the list of transfer_function keys, which includes 'emulator' and 'fitting_function'... ?

Apologies if this question is moronic or if I've missed something critical from a section of the documentation.

[elisachisari]

The transfer function options in CCL are the following (from ccl_config.h):

typedef enum transfer_function_t
{
  // If using an emulator for P_NL
  ccl_emulator          = 0,
  ccl_none              = 0,

  ccl_fitting_function  = 1,
  ccl_eisenstein_hu     = 1,

  ccl_bbks              = 2,

  ccl_boltzmann         = 3,
  ccl_boltzmann_class   = 3,

  ccl_boltzmann_camb    = 4,

} transfer_function_t;

While the matter power spectrum types are the following (from the same .h file):

typedef enum matter_power_spectrum_t
{
    ccl_linear           = 0,

    ccl_halofit          = 1,
    // more?
    ccl_halo_model       = 3,
    // even more kinds ...
    ccl_emu              = 4
} matter_power_spectrum_t;

The transfer_function option would specify, for example, using a Boltzmann code (CLASS in our case), but the same code could predict different type of power spectra (linear,halofit). Not all combinations are allowed though. For example, right now we only have one emulator, so the transfer_function=ccl_emulator and the matter_power_spectrum=ccl_emu must be used together. The idea with keeping it this way is that it gives us flexibility to incorporate new emulators in the future.

The currently supported combinations are:

• transfer_function=ccl_boltzmann (or equivalently,transfer_function=ccl_boltzmann_class) together with matter_power_spectrum=ccl_linear or matter_power_spectrum=ccl_halofit.
• transfer_function=ccl_emulator + matter_power_spectrum=ccl_emu
• transfer_function=ccl_bbks + matter_power_spectrum= any
• transfer_function=ccl_eisenstein_hu (or equivalently,transfer_function=ccl_fitting_function) + matter_power_spectrum= any

Anything else should crash - but it is likely we don't have a graceful exit in place at this stage.

In terms of implementation in the code, I was able to make the following schema of the flow of the power spectrum splines and the switches we use:

To summarise, I think we should implement graceful exits when the combination of transfer_function and matter_power_spectrum are not supported. And we should document this better in the note. Does this help? Let me know if there are further questions.

[philbull]

Thanks Elisa, this is super useful! When you say matter_power_spectrum=any in the last two items, there are situations where this would fail I thought? e.g. transfer_function=ccl_eisenstein_hu and matter_power_spectrum=ccl_emu wouldn't work?

I think having the flexibility you mentioned is worthwhile, but I feel that it's too confusing to have separate lists for the transfer_function and matter_power_spectrum settings when they are often (but not always) tightly coupled to one another. As an alternative, could we replace these two settings with a single power_spectrum setting (the name matter_power_spectrum is too verbose!), and just add each possible power spectrum + transfer function pair as a separate option in the list?

For example, the combinations you listed above would turn into:

ccl_class_linear, ccl_class_halofit
ccl_emulator
ccl_bbks_linear, ccl_bbks_halofit, ...
ccl_eh_linear, ccl_eh_halofit...

I got rid of some duplicate definitions, like fitting_function, to keep the list short. (We could potentially even get rid of the linear settings, as I'm not sure what the use-case for those is given that we have separate linear and nonlin matter power spectrum functions.)

That's only a handful of combinations, and there's no risk of choosing an incompatible transfer/matter power spectrum pair, as only allowed combinations are in the list. It's also easy to add new methods, e.g. ccl_emulator_ostrich or whatever. Would this alternative work for you? @elisachisari @alexander-mead ?

[alexander-mead]

Okay, I think I understand this a bit better now. I think my suggestion would be the following:

Could it be set such that when you initialise a cosmology object you set a method for creating the linear power spectrum (e.g., CLASS, Eisenstein & Hu, BBKS, CAMB, ...) and then, optionally, also a method for creating the non-linear power (e.g., PD96, halofit, CosmicEmu, halo_model, HMcode, FAST-PT, perturbation theory, ...)?

The linear power is almost always useful to have and most of the non-linear methods take this as an input and then apply a 'correction' to the linear power to get some non-linear power. The only exception to this rule from the list above would be the CosmicEmu, where some linear power spectrum has been assumed in the running of the simulations that were used to generate the emulator. In this case, I would suggest that the user be forced to get the power spectrum from a Boltzmann code when using the emulator, so that, for example, 'BBKS + emulator' was not allowed.

Let me know if I am missing something crucial here. Or if anyone has a better suggestion.

[elisachisari]

@alexander-mead

Could it be set such that when you initialise a cosmology object you set a method for creating the linear power spectrum (e.g., CLASS, Eisenstein & Hu, BBKS, CAMB, ...) and then, optionally, also a method for creating the non-linear power (e.g., PD96, halofit, CosmicEmu, halo_model, HMcode, FAST-PT, perturbation theory, ...)?

We could do this, and I can see some advantages to it, but my feeling is that many of these would be "incompatible". I think we need to figure out what combinations make sense for the user if we phrase it this way, compared against our current implementation. Worth running a poll on Slack?

The only exception to this rule from the list above would be the CosmicEmu, where some linear power spectrum has been assumed in the running of the simulations that were used to generate the emulator. In this case, I would suggest that the user be forced to get the power spectrum from a Boltzmann code when using the emulator, so that, for example, 'BBKS + emulator' was not allowed.

Currently, if you call the emulator, you get the linear power spectrum from CLASS. 'BBKS+emulator' is effectively not allowed and if you try to do that, CCL should quit.

[alexander-mead]

I'm not sure how many of the combinations would be incompatible, other than the cosmic-emu example. Which combinations were you thinking that might be incompatible? I think that given that most 'non-linear methods' can be used on any linear spectrum it makes sense to have two separate lists. One problem with just having a single list for matter_power_spectrum is that every time someone added a new non-linear method (e.g., FAST-PT) then you would have to create a whole slew of new options like 'BBKS + FAST-PT', 'Eisenstein & Hu + FAST-PT', 'CLASS + FAST-PT'..., rather than just a single one.

I think one thing that we all agree on is that having separate lists for transfer_function and matter_power_spectrum is too confusing, right?

In any case, I'm sure a poll on Slack is a great idea.

[beckermr]

I think the new docs in v2 make this more clear. I am closing for now. Please feel free to reopen!