draw template redshifts and magnitudes from more realistic distributions about desisim

[sbailey]

Drawing from n(z) would be handy, but we also need the option of making templates to match an exact input list of redshifts so that template making can be matched to an input mock catalog with known true redshifts.

[moustakas]

Defining the input redshifts from mocks is #104. But what else from the mocks should the templates inherit? Do the mocks include colors, luminosities, line-strengths, etc.? [We can take this back on-list if necessary.]

[sbailey]

Our current mocks only have (ra, dec, redshift, objtype). Future mocks may also have colors, etc. — Peder Norberg is particularly keen about that. Let's get the 0th order n(z) and user-defined redshifts implemented, and spin it to mailing list discussions with the cosmo sims group about what else may arrive and when.

Apologies I hadn't seen #104 when I commented on this. Perhaps this is obvious, but making sure: the implementations should be very closely related, i.e. this issue should sample n(z) to get an array of redshifts, and then call the exact same code as for a user-provided array of redshifts.

[sbailey]

In PR #132, @moustakas commented that this issue (#106) "...is probably obsolete since we're moving to more realistic mocks" That is true when using those mocks as input, but it would still be handy to have a simple, lightweight way of generating templates with approximately realistic n(z) and magnitude distributions based on parameters in desimodel. PR #132 did the heavy lifting for that, now it just needs a little wrapper to get the distributions from desimodel and call the make_templates code with the right inputs. Leaving this issue open.

[moustakas]

The template-generating code has moved toward requiring the user to do the hard work of inputting a sample (e.g., a mock) with realistic distributions of magnitude, redshift, etc., so I'm closing this.

[moustakas]

We were typing at the same time.... OK, reopening.

[sbailey]

To be clear: this could (should?) be done via get_targets; it doesn't have to be baked into templates.*.make_templates() at a low level now that those provide the basic infrastructure for generating targets with arbitrary redshifts and colors. The main point is that we should provide an easy way to generate a DESI-like population of targets (n(z), mags, [OII] flux) without having to go via a full cosmosim/mock . If the targeting WG updates the expected n(z) in desimodel, that should be sufficient for updating the inputs for this function to provide targets following that n(z).

I'll try to incorporate this into the updated get_targets as part of the refactor in #110 (that is about optionally connecting it to mocks/fiberassign; this issue is about what should be done if you don't connect it to those inputs). Thus reassigning to myself (to be done post py3...)

[moustakas]

Agreed, desisim.templates has (thankfully!) moved toward not having any knowledge of (astro)physics. I'm working on updating the n(z)'s in desimodel.

[moustakas]

desitarget/bin/select_mock_targets has evolved to do much of this work and we also have a ton of real data now to work with, so no further developments along the lines in this ticket are expected; closing.