Roadmap to turn classylss into a CLASS binding.

[rainwoodman]

Here is what I propose as a roadmap.

1. Implement pure python classylss.cosmology that can be constructed from Astropy cosmology objects, and yet delegates to CLASS for all function evaluation,

2. Reimplement a classylss.lss module that contains original functionalities of classylss.legacy, but in pure python, using mcfit.

3. migrate classylss.cosmology and lss to nbodykit. Now classylss contains only class binding, and nbodykit doesn't contain any compiled code.

4. Move the original lss routines to a classylss.legacy module. We break all code that uses classylss at this step, such that they can be clearly grepped and switch to nbodykit when necessary.

[nickhand]

Yes, I think I agree with this. A few questions:

• Are we trying to maintain as much similarity to Astropy syntax as possible? I do like their naming convention for most things, although we'll obviously need to change things to take full advantage of CLASS's functionality
• How quickly can we implement this? i.e., do we want it in the nbodykit paper? It feels like it should be. Perhaps if you start working on the "cosmology" module and I can start translating the Zeldovich code with mcfit

[rainwoodman]

• astropy names:
  I suspect not. Since we have to modify names anyways, we probably need to use the CLASS names but with nbodykit units.

• I don't think this is a blocker for the paper submission. The current cosmology module is good enough in the sense it works. But I agree it will be a mess if we are changing a lot of names. Is it possible to get this done this week? I'll start the cosmology module today.

[nickhand]

Yes, I think I would prefer to push on this and get everything working by the end of the month...I can start working on this as well asap

[nickhand]

okay @rainwoodman, here's what I am thinking for the next steps:

• tag and release v0.2.5 of nbodykit
• migrate cosmology and LSS routines to nbodykit v0.2.6 from classylss,
• remove gcl from classylss and tag v0.2.0

[rainwoodman]

I think we shall advertise classylss -- I am not sure where to.

Consider adding a few examples?

[nickhand]

I can try to put together a bare bone RTD with some examples for #18 -- shouldn't be too hard.

[nickhand]

The CLASS developers are aware? It would be good to avoid any potential friction caused by the fact that they have their own binding (I am not sure how well-maintained their binding is?).

We could potentially advertise on the astronomer's FB page? I am not sure if that is an okay thing to do...

[rainwoodman]

It is not yet well maintained, at least not to the level of classylss.

The best case scenario is to make classylss the go to binding and build a good channel with the class_public development. What about adding the two we have patches as PR to class_public first ?

If history is a lesson I remember there was a third party binding before and it stopped being developed or used. Then the class developer also agreed their current binding is insufficient in one of the posts.