Rest / obs frame inconsistency in sps library resolution?

[wangbingjie]

I finally have some time to take a look at v2, and I am a bit confused about how the spectral resolution is handled.... Specifically, in sed_model.py L131, we have

self._library_resolution = getattr(sps, "spectral_resolution", 0.0) # restframe

However, it looks like this rest-frame resolution is passed directly into instrumental_smoothing in observations.py, where the function expects it to be in the observed frame, as here we do

Klib = np.interp(self.padded_wavelength, model_wave_obsframe, libres)

Or perhaps I misunderstood something basic...?

[bd-j]

So, I think that because the model resolution is defined in units of velocity dispersion, it should be the same at lambda_r in the restframe as at lambda_o=lambda_r * (1+z) in the observed frame. But I might have been thinking about this wrong!

[wangbingjie]

oh got it! sorry a follow-up questions... If this is in km/s, then I don't quite understand as why there are negative values? I just checked this by

from prospect.sources import CSPSpecBasis
sps = CSPSpecBasis(zcontinuous=1, compute_vega_mags=False)
sps.ssp.resolutions

And my outputs are ... array([-8393.6446, -6771.4686, -5304.3171, ..., -2347.1481, -2351.2879,
-2342.3864])

[bd-j]

FSPS uses negative numbers to indicate/flag that the resolution is not particularly well defined, as the spectrum comes from lower resolution models based on line opacities that are simply summed in square bins. For work at much lower instrumental resolution that should not matter - it should possibly be the default in prospector to take the absolute value.

[wangbingjie]

Thank you! Yes taking the absolute value would probably be better? otherwise this assert would not always work:

assert np.all(self.padded_resolution >= Klib), "data higher resolution than library"

We just need to modify one line in predict_init where the resolution attribute is defined I suppose? I can create a PR for this If that sounds right?