Return "truth catalog" info / save truth catalog

[NiallMac]

For analysis of the sims, we'll want to know what exactly was drawn where. So I think for each exposure we'd want to return this information as well as (or as part of) seobs. At a minimum, we'd want, for each object drawn,

• Whether it was a galaxy or star
• The index from the galaxy/star catalog`
• ra/dec
• Any randomly generated properties that can't be reconstructed from the input catalog and the index e.g. if a random rotation is applied before drawing
  For the convenience though, we might just want to retain all the information about the object e.g. flux, morphology...

Also add tools for saving this stuff to file.

Let me know thoughts/preferences about how we set this stuff up, and whether I should take a crack at this or @esheldon or @beckermr you'd rather do it.

[esheldon]

Thanks Niall. Can you please list the primary use cases for this catalog? It will help to understand what is needed and how to implement it.

We don't do i/o in this library, so we would rather provide the ability to get the catalog and then the user can do the i/o

[NiallMac]

Good question. So my particular use case was for the n_gamma(z) calculations we've discussed. Specifically - I want to get an estimate of the redshift distribution of objects detected in a given simulation. It doesn't need to be perfect (because what does that mean with blending anyway), so being able to position-match the output catalog to the inputs, and then grab the corresponding redshifts, would be a sufficient and the most straightforward way to do this.

I imagine this would also be useful generally for testing that the simulation code is doing what we expect. Especially in simplified sims e.g. without blending, comparing input and output objects is a decent approach to doing so I think, but for that we need to keep track of what input objects we simulated and where.

[beckermr]

Yes. My student is adding this same set of analysis steps to the old mdet code as well. The positions and redshifts of each object should be sufficient to start. Estimates of the object's size might be useful for helping to differentiate things that are very blended versus not.

[esheldon]

Note we now do return bright_info, we could extend this to all objects

[NiallMac]

Sounds good - I can have a go at this - I'll just copy the way this is done for bright_info unless you have alternative suggestions?

[esheldon]

that sounds fine, add a new entry to the output dictionary, e.g. truth_catalog or whatever.