-
Notifications
You must be signed in to change notification settings - Fork 38
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
changing the emission line velocity width #229
Comments
Hi @moustakas! The lines are added with a resolution set by the wavelength spacing of the stellar spectral library, which for MILES at these wavelengths is ~1AA. Unfortunately this resolution is not adjustable at run time (though I think it could be made a bit narrower and still be well-enough sampled - looking through the code it seems the lines have sigma=2*delta_lambda which is pretty broad) One more general option might be to turn off the automatic addition of lines and construct them yourself from the computed nebular line luminosities and wavelengths (after augmenting the wavelength array...) e.g.
and then use these to construct and normalize whichever line profiles you want. |
Thanks for the quick response @bd-j! However, these models were computed with
Any thoughts what's going on? Regardless, I think I'll follow your suggestion and instantiate the lines myself. |
And can you confirm that for |
I think c3k_a is only R=3000 in the optical (but you can look at Yes, the units are L/L_sun when SFH=3 (and for other other SFHs are normalized by the total stellar mass formed) |
I'm not seeing an As for the resolution of c3k_a, according to this readme, However, if I model the [OIII] 5007 line with a single Gaussian, I get a sigma line-width of 1.676 Angstrom, or 100.4 km/s at a vacuum wavelength of 5008.238 Angstrom. But isn't that a factor of 2.355 too big? (Note: 100.4 / 2.355 = 42 km/s.) So I feel like (1) I'm missing something / wrong; (2) the c3k_a resolution readme is incorrect; or (3) there's a bug in the emission-line code. Thoughts? |
I agree the emission lines are broader than the resolution of the stellar library - I don't think the docs make a claim about the emission lines? As noted above, the emission lines are added with sigma=2 * delta_lambda = 2 * (lambda / R_FWHM /2) (see code at https://github.com/cconroy20/fsps/blob/master/src/add_nebular.f90#L45) which for c3k_a is a larger velocity dispersion than the stars by a factor of 2.35. I believe but am not sure that the reasoning was to be extra sure that emission line flux was conserved, though I do thank they could be made narrower and still be well-enough sampled. Also note that the special libraries - WR stars, AGB stars, etc are added with resolutions that do not match the C3K (or even MILES) libraries. |
Basically, the emision lines are added based on the wavelength spacing of the stellar library, but there's no guarantee that will be closely related to the resolution of the stellar library. Even if dividing by a factor 2.355 in Of course, now that we are more explicitly tracking the library resolution we could try to use that to set the nebular line widths. I will open an issue on FSPS for this. |
Thanks @bd-j. I've followed your suggestion and I'm now creating the emission-line spectrum on-the-fly with my desired line-width. Feel free to close this ticket, but hopefully with cconroy20/fsps#69 the end-user can have the option of controlling the emission-line width separately from the wavelength spacing of the SPS model spectra. |
Apologies if this information is in the documentation or in previously closed tickets, but I'd like to change (reduce) the velocity width of the emission lines without smoothing the stellar continuum. E.g., in the example below I would like to change the velocity width so the [OII] doublet is well-resolved.
According to the docs,
smooth_velocity=True
butsmooth_lsf=False
, by default, so there shouldn't be any supplemental smoothing. But clearly the lines are pretty broad (hard to tell, but I would guess >>100 km/s).Any advice or guidance would be much-appreciated!
The text was updated successfully, but these errors were encountered: