draw template redshifts and magnitudes from more realistic distributions

[moustakas]

When generating synthetic spectral templates, the redshifts are drawn from a uniform distribution between minimum and maximum values defined by the user (with sensible default ranges set by the spectral class). #104 is one alternative.

Another option is to draw redshifts from the expected redshift distribution n(z) for each target class. (Note that desisim.targets.sample_nz already does this---it's just not yet implemented.)

Similarly, the spectra are normalized to an apparent magnitude distribution (in a band which depends on the target class) which is also (unrealistically) uniformly distributed over a user-defined range. We should have the flexibility of drawing from an observationally constrained luminosity function, and then asking whether the object passes the faint-magnitude limit by computing the distance modulus and K-correction.

Note that code to draw from the QSO luminosity function has already been implemented here.

[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.