Output list

[evavagiakis]

This might have been discussed in another thread but I cannot find it (maybe it was just on slack). Thinking about what to output from the SZ sims and save in one .h5 format catalog, per halo:

• z
• M (M200 or Mvir, not yet decided)
• ID number (method not yet decided)
• c200 (? This was output last time. I have not yet found where it's used in the old scripts, if it is used at all. It's not used for Battaglia. It might be used for an NFW profile if we decide to keep that functionality. For now, I'll leave it, but it might make sense to eliminate later)
• [Not the profile; the profile can be expressed from z, M, and saved inputs from the .yaml]
• Temperature submap with all observational effects included (the final simulated submap output; y map could also be computed after the fact using frequency conversion)
• The noise map (? This will not be able to be derived from inputs/equations, so I am wondering if it is worth the storage to include the noise in the output so the user can remove the noise from the temperature map for whatever reason. If not the noise map, some parameter describing the noise level could be saved in the input. This is not currently included)
• y measurement (? We could use aperture photometry for a defined or user-input radius or this could be a central value; if the central value, should this be from the profile itself, or the simulated submap? And if the submap, at what point (final, before noise injection, etc.? I assume this would be convenient to include as part of a Y-M plot; if so, maybe we should motivate this choice based on what would be best for that)

[bnord]

1. What will be the observable submap that we want to infer Mass from? Is that a temperature map/
2. If the map can't be derived from anything, I suggest keeping it. Or we could do a quick back-of-the-envelope estimate of file size, and ask if if we have storage for that. I think we do.
3. for the y0 or ycentral measure, I think this would be good to keep and to measure from a noisy submap -- my logic for this guess is that it is close to what people do when measuring things on SZ maps. (or at least it was when I worked on this kind of thing last).

[evavagiakis]

1. We had been wanting to infer mass from the "real observed" temperature map. However, I could see it being interesting to infer mass from a number of different maps (for example, a cleaned y map, to compare to compton-y map measurements) in the future.
2. I'll plan on storing the noise map too as long as it's feasible
3. I'll plan on taking the central pixel value from the temperature submap and making sure the maps are shaped to make a central pixel easy to extract (i.e. there is a single central pixel and an odd number of pixels on each side of the submap)

[bnord]

cooooolio.

Once we settle on our list for alpha, we can start turning this discussion into one more tasks for someone to figure out how to save these types of data to an h5.

It sounds like we're about there, but not sure.

[evavagiakis]

Sounds good. Before we get there, we'll need to write the code that outputs these quantities. Then we can assign a to-do to someone for output

[bnord]

Here's a proto-design for some data structure, which we should plan ahead. Planning ahead will help us know what kind of class or other data structure might be necessary, and will likely prevent having to rewrite code or will reduce the number of iterations.

Draft design: Each object (halo/cluster) will have the following properties
1. Mass (float, 1dim)
2. redshift (float, 1dim)
3. concentration (float, 1dim)
4. ID (int, 1dim)
5. Temperature submap (float, 2dim)
6. noise submap (float, 2dim)
7. central y measurement (float, 1dim)

Is this correct? or close to correct?

[evavagiakis]

This looks good to me! @kbanker please go ahead and work on saving that list of outputs