Check out CosmoMAD about ccl HOT 8 CLOSED

hi Anze, I have been following what is going on in CCL from far away,
but I am surprised by all this. Why not use and develop a large C system
like CLASS, rather than pick stuff around to reinvent the wheel. I am
interested in all these tool-gathering efforts in theory, but I am
unclear about what the decisions are when choosing between
reimplementing and integrating software.

best,

Johann

On 05/09/2016 22:01, Anže Slosar wrote:

@damonge https://github.com/damonge @elikrause
https://github.com/elikrause @joezuntz https://github.com/joezuntz
Guys,

This is not really an issue, since it is not clear what could close
it, but in absence of other tools:
check out this:

https://github.com/damonge/CosmoMA

and the example in the doc:
https://github.com/damonge/CosmoMAD/blob/master/doc/CosmoMad.pdf

It does seem pretty similar in spirit to CCL, I guess we can just
copy-paste much of the code from there.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#27, or
mute the thread
https://github.com/notifications/unsubscribe-auth/AAjxYc2R4lGsW4QvueTB28mswJqHgV09ks5qnHUMgaJpZM4J1S29.

from ccl.

Hi Johann,

I don't know, I've been following it from far away too until last week. :)

I think @elikrause and @joezuntz should explain further, but my understanding was that we wanted a code under our control with well-understood accuracies and control sets.

I think the issue with CLASS is that it is too tightly focused to do CMB calculation. I.e, not sure how simple it is to simply make it spit out some distances without doing the full linear calculation. But on the other hand, reinventing neutrino background and stuff which you really need even at lowz for good accuracy is a bit painful. But maybe starting with something like CLASS or cosmomad might be easier and then just write a suite of accuracy ensuring tests...

In fact, I think the statement I subscribe to: I agree there should be an "official" cosmology library for the collaboration, so we know that some random grad student didn't screw up the hubble law in his code and for general consistency and ease of linking the codes. But it is not clear whether we should write one from scratch, rather than adopt and adapt.

from ccl.

I think a key issue that (in my mind) both @elikrause and @joezuntz are addressing is to have a well known/understood code to use as the overarching test code - but that was flexible to allow people to "plug and play" their own codes into.

Correct me if I'm wrong, but my understanding from the discussions around this in Oxford was that the goal isn't to reinvent the wheel ie. CLASS/CAMB etc. but to make the CCL a broad framework that people could build on and link their codes to eventually, but that we had a benchmark for any tests.

from ccl.

Hi all. As Renee says, we're not reinventing the wheel - the main part of the CCL is an interface to CLASS with accuracy settings that we know are sufficient for LSST needs.

Joe

from ccl.

HI all,

I agree with Johan and think that writing an interface to CLASS is very
tricky.

As of precision needs, this is controlled in class by a file of
precision paarmeters and we could simply write our own set (without
changing the structure)

Another point for CCL is the possibility of being modular and for
instance switch the P_NL model (as coyote emulator).

But this should also be done within class (that is modular too): indeed,
if you change P_NL you change your total P(k) and this has an incidence
on the CMB lensing. You may say it is negligible but for very high
precision measurements (as neurino masses) it actually matters.

I think a better approach would be to developp our own CLASS branch.

regards

stephane

what would be more interesting is to provide a simple interface to
common class/camb/cosmoMAD observables for comparison.

Le 07/09/2016 à 15:43, joezuntz a écrit :

Hi all. As Renee says, we're not reinventing the wheel - the main part
of the CCL is an interface to CLASS with accuracy settings that we
know are sufficient for LSST needs.

Joe

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVf5rL59CJDmg100lie_SBQsteVbXxhks5qnr9pgaJpZM4J1S29.

S. Plaszczynski
Laboratoire de l'Accélérateur Linéaire
Centre d'Orsay- bat 200
BP34- 91989 ORSAY cedex

tel: 01 64 46 85 38

from ccl.

Again, I think the point is that theorist are infinitely creative and will come up with their own codes/modifications that they want to test with LSST data (I have > 5 different ones myself!), so making the CCL tied to any one particular code is not a good idea.

This general approach that @joezuntz and @elikrause (and @elisachisari @damonge!) are taking is exactly to do the work making it simple to interface whatever code you decide to use in the future, not only making us work with the suite of codes that are out there today.
It's hard work, but it makes my future life much easier, and hopefully we will be able to swap out emulators (indeed, almost any part of the functionality if it is modular enough) too.

from ccl.

this addresses a different question about the models tested. In any case
they will require a dedicated implementation and it will be simpler to
do it directly within class (I mean a dedicated branch). this is how
hiClass did.

Le 07/09/2016 à 19:53, reneehlozek a écrit :

Again, I think the point is that theorist are infinitely creative and
will come up with their own codes/modifications that they want to test
with LSST data (I have > 5 different ones myself!), so making the CCL
tied to any one particular code is not a good idea.

This general approach that @joezuntz https://github.com/joezuntz and
@elikrause https://github.com/elikrause (and @elisachisari
https://github.com/elisachisari @damonge
https://github.com/damonge!) are taking is exactly to do the work
making it simple to interface /whatever/ code you decide to use in the
future, not only making us work with the suite of codes that are out
there today.
It's hard work, but it makes my future life much easier, and hopefully
we will be able to swap out emulators (indeed, almost any part of the
functionality if it is modular enough) too.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVf5gUPOreY2edbOhhq4o8OkipxKCjRks5qnvo1gaJpZM4J1S29.

S. Plaszczynski
Laboratoire de l'Accélérateur Linéaire
Centre d'Orsay- bat 200
BP34- 91989 ORSAY cedex

tel: 01 64 46 85 38

from ccl.

Hi all,

Many thanks for the discussion here - interfacing with codes like class is certainly a core part of the goal of CCL and we're all very focused on it! We'll certainly keep in mind the various issues people have raised here.

All the best,
Joe

from ccl.