Map out modules for the code

[cavestruz]

Map out modules for the code (e.g. readers, observing strategies, M-c relations, (mis-)centering options and implementations, model profile to fit for mass (NFW, Diemer+, etc.), etc. This would also be a good place to decide what the focus of CLMassMod should be.

[aimalz]

In response to yesterday's call, it seems like we want to have at the very least:

• a superclass of readers for data (simulated and observed) that could be used in an analysis
  • a subclass for readers of simulation files with class instances for each simulation so it's easily extensible to simulations to which we don't (yet) have access
  • a set of subclasses for readers of outside data files (one class per general type of data, i.e. x-ray/SZ, etc.) with class instances for each dataset so it's easily extensible to datasets to which we don't (yet) have access
• a class representing an individual cluster (e.g. clmassmod.cluster)
  • class methods to fit various properties (e.g. clmassmod.cluster.fit_nfw() or clmassmod.cluster.fit_mass_pdf(), etc.)
• a class representing an ensemble of clusters (e.g. clmassmod.ensemble), which may be a wrapper for many instances of the individual cluster class
  • a class method to take the mean of some property of the ensemble by stacking in bins over some variable (e.g. clmassmod.ensemble.stack_mass(over_property='richness', bin_defs)) Note: I'm not super clear on how this fits into the big picture of cosmology analysis, so this might well be way off from what people have in mind.

Does this sound like the right track? If folks agree, I can develop these in the wishlist notebook before next week's meeting.

[cavestruz]

Yes! Thanks @aimalz , that would be awesome. Though, I think the class method to fit various properties should be able to also treat a stacked ghat map. From what I understand, fitting for profile parameters for stacked versus individual clusters with higher signal-to-noise could be treated as a similar process. But, this would be a good thing to check with @tmcclintock, @brandynlee, and @matthewwf2001

Thought: Maybe fitting functionality could be generalized as an inherited class in both clmassmod.cluster.fit(ProfileFitting) and clmassmod.ensemble.fit(ProfileFitting)? Or is this not a great way to generalize the code.

One thing to get group feedback on is - what would be a good way to separate out ongoing code development that lifts code from Doug's modules? Are we doing this in jupyter notebooks that we will then later collate into a completely refactored code base?