Cosmological dimming of spectral flux with 'lumdist' or 'zred'

[gkhullar]

Hi,

This is a question to understand more of how Prospector v0.3.0 is doing cosmological dimming via 'zred' and/or 'lumindist' parameters in model dictionaries.

I am currently using Prospector to fit models based on CSPSpec sources to my spectra, by stacking them across stellar mass and redshift. My spectra are typically in the redshift range 0.3-0.7. I nominally do this spectral stacking by moving all observed spectra to their rest-frame wavelengths, resampling them on a common grid, and then fitting Prospector to mean stacks across mass and redshift bins.

What I was doing initially was instead of moving the rest-frame spectra back to the observed wavelength range corresponding to the stack redshift and specifying 'zred', I turned 'zred'=0 and supplied the model object a luminosity distance (via 'lumdist') by calculating it manually via WMAP9, which I see is what the get_spectrum function does under ssp_basis here:

https://github.com/bd-j/prospector/blob/master/prospect/sources/ssp_basis.py

Pointing to lines 209-221 here

    a = 1 + self.params.get('zred', 0)
    af = a
    b = 0.0

    if 'wavecal_coeffs' in self.params:
        x = wave - wave.min()
        x = 2.0 * (x / x.max()) - 1.0
        c = np.insert(self.params['wavecal_coeffs'], 0, 0)
        # assume coeeficients give shifts in km/s
        b = chebval(x, c) / (lightspeed*1e-13)

    wa, sa = wave * (a + b), spectrum * af  # Observed Frame

Only if I supply zred!=0 will the inverse of scale factor i.e. a be multiplied to the spectrum and dfactor be calculated towards cosmological dimming. If zred==0 and lumdist is provided, the same dfactor is calculated, albeit without the spectrum*a operation. My question is: why is the scalar 'a' being multiplied to the spectral flux here?

If this is indeed just an oversight on my part from a cosmology conceptual standpoint: Since this would create a redshift dependence to my stellar mass calculations, does this mean Prospector recommends fitting spectral data in the observed wavelength frame only, with an explicit zred parameter specified?

[jrleja]

Hi Gourav,

The luminosity distance accounts for the scaling of flux with redshift; however, the units of the spectrum are flux densities rather than flux, which requires an extra factor of a=(1+z).

Using the lumdist keyword neglects this effect as you've noticed. The lumdist keyword is built to handle nearby objects, where the luminosity distance is typically decoupled from the redshift due to peculiar velocities.

does this mean Prospector recommends fitting spectral data in the observed wavelength frame only, with an explicit zred parameter specified?

This is the design intention. It can be altered but I'd recommend doing this carefully -- as you have been doing -- because different aspects of redshifting are handled in different locations in the code.

I think the most straightforward solution for you is to continue using the lumdist keyword, and apply the extra (1+z) factor outside of Prospector, if you haven't already.

One last note of caution: many features in galaxy spectra have a non-linear mapping between physical parameters and the observed flux, including key basic parameters like age, dust, and metallicity. This can make the interpretation of stacked spectra challenging, and is good to keep in mind when doing the analysis.

[gkhullar]

Hi Joel

Thank you for your response. This was indeed very helpful. I am currently doing all my spectroscopic analysis in the observed frame, so am just relying on the zred parameter to do the distance dimming for me.

I am wondering if you could elaborate a bit on your last point. My redshift bins are spaced approximately 0.5-1.0 gigayears apart. Do you suspect that an SPS analysis of a median stacked spectrum of a diverse set of galaxies in this timespan could bias results in some way, because of the non-linear mapping of properties?

Happy to close this issue after this. Thanks!

[jrleja]

Hi Gourav,

In a word, yes. It's hard to give a good estimate of the size of the bias from first principles however. Depending on your wavelength coverage, S/N, and parameters of interest, it can range from negligible to substantial.

Just to be perfectly clear on the basic issue, the upper-right panel of Fig. 1 here is a good example. The true average metallicity of these three templates is ~0.008. But if you were to stack their spectra and measure the metallicity from the stacked spectra (assuming some fixed age for now), it would be higher than that because of the nonlinear relationship between flux & metallicity.

In real galaxy spectra, the problem is more complex since age (really, not age, but the full star formation history) also typically has a nonlinear effect on absorption lines. Dust, too, has a nonlinear effect, though this is often a bigger concern when stacking photometry, which has a longer wavelength baseline. The method by which the spectra are stacked will also interact with the size of the bias, as well as the exact underlying distribution of SFHs, metallicities, and dust properties in the target galaxy population.

So, there's not a single answer to this question. If you're interested in exploring this for your data, one approach might be fitting spectra of some individual objects, then stacking their spectra and fitting the stack. You can compare the average age, Z from the individual fits to the age, Z inferred from the stack to get a rough estimate of the size of the bias.

--Joel

[gkhullar]

Thanks, Joel. This discussion was ultra helpful!