review the set rest-frame bandpasses and band shifts

[moustakas]

At the moment, we compute K-corrections and rest-frame photometry in the following bandpasses (see https://fastspecfit.readthedocs.io/en/latest/fastphot.html):

• Johnson-Morgan UBV band-shifted to z=0.0;
• WISE W1W2 band-shifted to z=0.0; and
• SDSS ugriz band-shifted to z=0.1 (in order to match previous luminosity function work).

Do we want to expand this list (e.g., compute DECam ugriz)? Of course, any changes will expand the data model, so we don't want an infinite number of bands.

Related: https://github.com/desihub/fastspecfit/issues/74

[deisenstein]

My two cents:

DESI covers enough redshift range, even in BGS, that I don't think there's much to gain in being clever, e.g., ooh, this filter at this redshift matches to that filter at a reference redshift.

I agree that ugriz at z=0.1 is the best for comparing to SDSS-based LF work. And that UBV at z=0 is another common standard.

I'm less familiar with what work has been done with W1W2 at z=0, but no objections. That said, should this be considered for 0.1 instead?

I am wondering about whether we should include rest-frame 2MASS H and K. First, there was 2MASS work at these redshifts. Second, it seems to me that WISE measurements of LRGs at 0.4-1.1 are not really probing W1 rest, but more rest K or even rest H. And usually blueward of the 3.3 micron PAH feature.

I'm a little concerned that u(0.1) doesn't get far enough in the UV to represent the ELG selection band. So perhaps we should do g at z=1? (roughly 2400A) This is also r at z=1.6, so we'd have reasonable interpolation. Maybe we'd need to do grz at z=1 in that case?

The same issue doesn't come up for the LRGs, because r & z band stay reasonably contained by ugriz(0.1). E.g., r(0.8-0.9) is pretty close to u(0.1).

I stress that separately from the choice of bands, it matters how one is going to evaluate the answer. Is one doing a K-correction from a consistent observed band, or the closest observed band, or just evaluating the model (and hence kind of using all of the bands)? I think it is important that the data model supply the information that would allow one to change that choice. Typically I think this means that one should report the evaluate the model at the observed bands and observed redshift, so that one can construct different versions of the K corrections.

I hope this helps!

[ShaunMCole]

For BGS we've been working with SDSS grz at z_ref=0.1 as per your choice and are completely happy with that. We were planning to make some W1 and W2 luminosity functions and if all were presented together it would be more consistent to keep z_ref=0.1 but if z_ref=0.0 is the norm in that field then I think that would be OK with us.

We mainly work with polynomial fits to John's for sets of objects in bins of rest/reference frame g-r colour. To the extent that they work (and they seem to work very well for our purposes), we can transform to an alternative z_ref analytically. So no need to have multiple z_refs on our count.

[moustakas]

Thanks for the useful feedback, @deisenstein and @ShaunMCole.

I've settled on:

• UBV, z=0.0
• SDSS ugriz, z=0.1
• 2MASS Ks, z=0.1
• DECam grz z=1.0

And I'm planning to drop WISE W1, W2 z=0.0 unless someone advocates for them.

[ShaunMCole]

We do want W1 and W2 k-corrections at some fiducial redshift don't we? I'd go for z=0.1 like you have for SDSS and 2MASS bands. They will be useful for BGS objects...

Shaun

---

From: Moustakas @.> Sent: 04 August 2023 15:04 To: desihub/fastspecfit @.> Cc: COLE, SHAUN M. @.>; Mention @.> Subject: Re: [desihub/fastspecfit] review the set rest-frame bandpasses and band shifts (Issue #141)

[EXTERNAL EMAIL]

Thanks for the useful feedback, @deisensteinhttps://github.com/deisenstein and @ShaunMColehttps://github.com/ShaunMCole.

I've settled on:

• UBV, z=0.0
• SDSS ugriz, z=0.1
• 2MASS Ks, z=0.1
• DECam grz z=1.0

And I'm planning to drop WISE W1, W2 z=0.0 unless someone advocates for them.

— Reply to this email directly, view it on GitHubhttps://github.com/desihub/fastspecfit/issues/141#issuecomment-1665664508, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGVUPWX37XOCBHPZEKVVXA3XTT6OJANCNFSM6AAAAAA263YF3A. You are receiving this because you were mentioned.Message ID: @.***>

[moustakas]

@ShaunMCole the FastSpecFit catalog is up to 872 columns per object (although 765 of those are from the 45 emission lines I measure), so I was hoping to trim things down... Would keeping just W1 (but band-shifted to z=0.1) be OK with you (i.e., drop W2)?

BTW---a quick search of the literature revealed just a couple WISE luminosity functions---Dai+09 and Lake+18, but those have a combined total of 40 citations. The Bell+03 Ks-band luminosity function paper on the other hand has >1900 citations. One of the main differences, of course, is the inclusion of the stellar mass function, which would be interesting to do from {0.1}W1 using, e.g., Jarrett+23, to complement other estimates of stellar mass.

[stephjuneau]

I put a vote for W1W2 (and would even like W3 even if more limited) at z=0.1 to go with ugriz at z=0.1

[moustakas]

Thanks for everyone's feedback. The final set of bandpasses are listed in this parameter file: https://github.com/desihub/fastspecfit/blob/main/py/fastspecfit/data/legacysurvey-dr9.yaml#L43-L56

See this notebook for computing K-corrections and rest-frame photometry in other bands: https://github.com/desihub/fastspecfit/blob/main/doc/nb/tutorial-kcorrections.ipynb

BTW @deisenstein I had to leave off 2MASS due to an issue updating the filters in speclite, although I'll revisit this once that ticket is resolved-- https://github.com/desihub/speclite/pull/79