comments on code and notebook structure

[samueldmcdermott]

Here's some thoughts on state of the code as of Oct 4, 2023. This may be revised (since I don't have a perfect understanding of all the moving parts yet, but I thought it better to write this down sooner rather than later), and if it is I'll try to remember to make a note of when the revisions happen.

Comments:

1. class no longer needs to inherit from object, so you may omit (object) from the classes you define (I see this in read_yaml and load_vars)
2. make_dm_halo needs more documentation (eg units on m500min and m500max; also, should these be uniformly distributed or log-uniform? or what if you wanted to have choices other than a uniform random distribution, could you set a kwarg for even spacing, log uniform, etc?), and/or to be renamed (you're making a sample of different seeds, not a single DM halo with a density profile, etc) and/or to be consolidated with some other module
3. I find the notebook a little confusing, on the whole. Two comments related to this:

• this is a good place to use the new nesting/collapsing feature of jupyter-notebook -- put in some additional headings so that it's clear what each "phase" of the notebook is building towards, and have them collapsed by default so it's easy to navigate
• I think it might be useful to "think backwards" from some output that you want (a map of the CMB plus a SZ cluster, with noise and instrumental effects) to engineer the code (some kind of plotting class whose instances include cluster, cmb, and noise attributes, perhaps)

4. biggest comment is that it should be a little easier to get an SZ cluster map without having to know about all of the intermediate steps (related to the previous point)

Questions:

1. why are some imports in the import pkg.module as module form and some in the from pkg import module form? And is there any reason that we are dropping the context, eg why not just import simsz (or import simsz as sz if you want to save typing)?
2. are all of io_params, load_vars, and read_yaml being used? They have similar-sounding names and each defines a single class, so it might be more useful if there was a single module whose name included one of io/load/read and it contained a few different classes for your different use cases... if this is on the right track, can they be consolidated?
3. likewise, simtools and utils kind of sound similar. Can these be consolidated?

Overall, it seems like there's cool physics here, just trying to help make it more visible!

[elaine-ran]

I think Eve and I were also confused on why there were so many different forms of importing for the notebook. Should we just use import simsz and get rid of all the imports?

[samueldmcdermott]

yeah, I think import simsz is best (or import simsz as sz to save a few keystrokes later if you want)

[evavagiakis]

I've deleted the old/redundant notebooks and changed the names of the two notebooks to "demo_simulation" and "demo_full_pipeline" to try to differentiate between the notebook in which we demonstrate the simulation function (that hides the intermediate steps) and the full pipeline notebook that runs through all the functionality in the simulation. Any comments/critiques on these names?

Question: with the new demo_simulation notebook there is now a massdist.h5 and an sz_sim_data.h5 file in the notebooks folder. Do we want these in the notebooks folder or should we put them in another subfolder (like we have for outfiles)? @samueldmcdermott @elaine-ran

[samueldmcdermott]

yeah, even if it's a pain to get the paths correct and manage all the files, I think it's good practice for the folder names to be clearly representative of their contents, so notebooks should contain only ipynb files or other notebooks (and outfiles should have outputs, something like catalogs could have arrays of masses or other distributions that you want to use as inputs, etc)