add band_shift option

[moustakas]

Are you familiar with synthesizing photometry using a band_shifted filter curve? By band-shifting the filter curve to the median redshift of the sample you minimize the K-correction -- see Section 2.3 of http://arxiv.org/abs/astro-ph/0205243.

The option could either be added to load_filters by simply dividing the filter wavelength array by (1+band_shift), or it could be an optional input to get_ab_maggies so the band-shifting can happen on-the-fly. I need this capability in order to connect the BGS mock galaxy catalog to the BGS templates in desisim.

[dkirkby]

Do you want to calculate AB magnitudes using band-shifted filter curves, or evaluate K corrections? The filters module already has support for arbitrary filter convolutions, so it would straightforward to implement the denominator of equation (11) in the paper (below) if that's what you actually need.

[moustakas]

Calculating and returning k-corrections would be a nice future feature, but all I need right now is to get the AB magnitudes and maggies via a band-shifted filter curve.

[dkirkby]

The load_filter(s) methods cache previously used curves by name, but that would break if the same name could be used with different shifts. Therefore, it will be easier to add band_shift (or band_redshift?) as an optional parameter to methods that use a previously loaded filter.

By the way, is there an equivalent calculation that applies a redshift factor (1+z)/(1+z0) to the spectrum of an object with redshift z, instead of shifting the filter response?

[moustakas]

I leave it up to you to decide what to call the optional input. band_shift has the advantage of historical (SDSS) precedent, and also note that the bandpasses is blueshifted by 1+band_shift, so band_redshift may cause confusion. Maybe band_blueshift would work?

As for an equivalent calculation using the spectrum of the object, no I don't think it works out -- I'm pretty sure you actually have to do the convolution of the blue-shifted filter curve with the intrinsic spectrum (which is at redshift z.)

[dkirkby]

Now I am confused! I am looking at eqn (10) in the paper, which divides frequency by (1 + z0), so isn't this a redshift?

[moustakas]

I'm in an all-day meeting so can't look at this in detail right now, but here's Blanton's C implementation: https://github.com/blanton144/kcorrect/blob/master/src/k_projection_table.c

See especially this comment and code tidbit.

[dkirkby]

Perhaps @blanton144 can shed some light on this?

Michael: we are trying to reconcile eqn (10) of http://arxiv.org/abs/astro-ph/0205243, where z0 redshifts the filter:

with the kcorrect code which appears to blueshift by the band_shift parameter:

    cr_filter_lambda[l]=filter_lambda[maxn*k+l]/(1.+band_shift);

[dkirkby]

I created PR #22 so you can see what I have so far.

[blanton144]

I think Equation (10) is correct, and that it is blueshifting the filter.

Say the peak of R is at frequency nu0. Then the peak of ^{z0}R should be at nu0(1+z0), that is it should be blueshifted to higher frequency. In Equation (10) this means ^{z0}R(nu0(1+z0)) = R(nu0*(1+z0)/(1+z0)) = R(nu0), which is exactly what we want to be the case.

Right? I'm a little road-tired right now so maybe I'm not seeing something obvious.

Note that R is a fractional throughput of photons, which is why there isn't a normalization transformation here (I think).

Anyway, please correct me if this is wrong.

I think the code is just shifting the wavelengths that correspond to the filter, and blueshifting them properly.

It might be that the 2007 paper explains this more clearly, or the Hogg astroph K-correction paper.

[blanton144]

And, I guess it doesn't take long for people to notice you've moved your repo to github.