Fold CAMB access into Astropy cosmology

[nstarman]

In Astropy we have a new bridge structure for mapping objects to/from an Astropy Cosmology -- https://docs.astropy.org/en/stable/cosmology/io.html#custom-cosmology-to-from-formats.

I've been meaning to add a CAMB bridge but haven't gotten the chance. Since you've done the hard thinking and work of mapping to/from CAMB, it should be possible to fold the mapping into Astropy.

If you're interested, I'd love to discuss further.

[ntessore]

Hi @nstarman, happy to discuss! Do I understand it right that the cosmology to/from functionality in Astropy would take a CAMB pars/results object and return an equivalent Astropy cosmology instance?

If that's the case, then I'm afraid I have done only some of the hard work -- and it seems hard work indeed to get the results exactly right. In fact, you could say that the entire reason for this package is to not have to figure out such a mapping, but instead simply provide a common interface to the methods of each underlying cosmology instance.

That being said, if you want to get things mostly right, you could probably look at what the parameters in the CAMB adapter [1] return and map it e.g. to a LambdaCDM instance.

[nstarman]

Sorry, I missed seeing this notification!

Do I understand it right that the cosmology to/from functionality in Astropy would take a CAMB pars/results object and return an equivalent Astropy cosmology instance?

Yes, long-term I would like to handle native conversion between the two, but your point "it seems hard work indeed to get the results exactly right" is well taken!

you could say that the entire reason for this package is to not have to figure out such a mapping, but instead simply provide a common interface to the methods of each underlying cosmology instance.

That also sounds like a worthwhile endeavor. In fact, I liked the idea so much I've opened https://github.com/astropy/astropy/pull/14242, if you are interested in contributing! The plan is to make Protocols defining the API for the Astropy cosmologies and wrappers, like the ones in this library, but conforming to the Astropy API. Then in an affiliated package (e.g. a astropy-cosmology-ext or some such) define the wrappers for CLASS, CAMB, etc. I'd be very happy to combine forces on this, if you're interested in adapting parts of this library.

P.S. Looking at this package, I see some interesting methods, like the <distance>_inv, that would be great to add to Astropy core as methods on FLRW! I'd be happy to assist on a PR, if you're so inclined.

[ntessore]

Hi @nstarman, happy new year.

The idea of having a (lowercase "p") protocol is what this package is all about, really. As a matter of fact, we now have a couple of new "big" codes that use this package's interface as an abstraction of the various Boltzmann codes, or indeed Astropy if only background quantities are required.

Looking at astropy/astropy#14242, what do you thing about factoring the interface/Protocol out into a standalone package? I think that would give it wider appeal than making it part of the Astropy package itself, and I don't see any downsides from your side. Which is exactly what the Cosmology package is supposed to be doing, so why not use it for that purpose?

The interface can be the Astropy one, I don't mind introducing such a breaking change at this early stage. The adapter machinery with auto-generation of missing methods can be separated from the interface/Protocol. But, again, I think it is important that the interface package is independent and standalone if it is to achieve any sort of adoption. ("I don't want to add Astropy as a dependency, I have my own cosmology classes!")

[nstarman]

Looking at astropy/astropy#14242, what do you thing about factoring the interface/Protocol out into a standalone package? ... Which is exactly what the Cosmology package is supposed to be doing, so why not use it for that purpose?

I think that would be a great idea. In which case, #14242 should mostly be moved to this package! Of course there are a lot of details to figure out, e.g. input and return types, governance and versioning of the standard, etc. If you have time next week, I'd be happy to chat by Zoom. My email is n.starkman[at]mail.utoronto.ca.

The interface can be the Astropy one, I don't mind introducing such a breaking change at this early stage.

Great! That will certainly help on the Astropy-governance side, where we are likewise wary of introducing dependencies. Protocols instead of base-classes and an Astropy-similar-API should largely alleviate those concerns.

The adapter machinery with auto-generation of missing methods can be separated from the interface/Protocol.

Agreed. They can mostly be moved to the wrappers, like in this package, from the Protocols.