Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow sigma_smooth to adjust photometry #227

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

elijahmathews
Copy link
Contributor

Currently, SpecModel does not respect the user's sigma_smooth parameter when predicting photometry; photometry is always computed based on a smoothed spectrum with sigma_smooth set to the default of 100 km s⁻¹. This edit should allow the user's sigma_smooth parameter to adjust the photometry as one would expect.

However, it should be noted that nebline_photometry also does not respect sigma_smooth and that is not addressed by this edit, and thus the predicted photometry is likely incorrect in the case where nebemlineinspec == False and sigma_smooth != 100.

@jrleja
Copy link
Collaborator

jrleja commented Oct 1, 2021

This is important for narrow-band photometry.

As Elijah notes, one (difficult?) extension of this would be to include emission line morphology in the photometry when modeling spec+phot and using the marginalization scheme.

@bd-j
Copy link
Owner

bd-j commented Oct 3, 2021

Thanks for bringing this up.

So this exposes some approximations used by SpecModel. Both the instrumental and physical (velocity dispersion) resolution are handled by a single call to smoothspec as it is potentially a bottleneck. Obviously the physical resolution will affect the SED for photometry, but the instrumental will not, and in the case of say grism spectra smoothing by the instrumental resolution may cause noticeable errors in the (narrowband) photometric calculation. The stellar library resolution plays into this as well in an important way (since sigma_smooth is added to it in quadrature to produce the output spectrum). @jrleja you may remember discussions on this point during the development of SpecModel.

A solution is perhaps to have an optional second smoothspec call in predict_spec() for the instrumental resolution, if it is not being handled by pre-smoothing the SSPs in FSPS (in which case the photometric predictions will be affected anyway in a way that cannot be fixed within prospector).

As for the emission line morphologies, it's not difficult to include it in the photometry -- a call to SpecModel.predict_eline_spec() should do it, where the linewidth is controlled by the eline_sigma parameter -- but the present scheme is supposed to be faster. I also note that nebline_photometry does not even respect the 100 km/s default smoothing - it simply adds all the line-flux using the filter response pixel closest to the observed frame line wavelength.

One other thing to note is that the lines -- when added by SpecModel instead of FSPS -- have zero intrinsic width, so eline_sigma really is their output width, whereas the stellar continuum has some library resolution which is added to sigma_smooth to produce the output.

@bd-j
Copy link
Owner

bd-j commented Oct 3, 2021

also just to clarify I believe in the current setup photometry is always computed at the native FSPS spectral library smoothing and does not have additional 100km/s smoothing (since it based on _norm_spec before any call to smoothspec)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants