Issue with Smooth Continuum in FastSpecFit

[Ragadeepika-Pucha]

@moustakas @stephjuneau There are two separate yet related issues that I found with the smooth continuum in FastSpecFit:

1. Excess continuum subtraction near the Balmer regions "eats" away the broad component. An example spectrum is shown below, where the black is the emission-line spectrum and the grey line indicates the smooth continuum component for the galaxy:

Example TARGETs that are affected in this way: 39633010890377403, 39633105035725300, 39627805847195825. I could only find a handful of such cases.

2. The smooth continuum subtraction leads to an excess subtraction, leading to an uneven continuum around the emission-lines. There are ~30 sources that I found which are affected by this issue. An example is as follows:

Example TARGETs that are affected in this way: 39627908800577649, 39627770271109086, 39632996646520846, 39633114426773787, 39633453762741009.

[moustakas]

Thanks for the specific examples, @Ragadeepika-Pucha. One quick request for the future: if you could provide not just the targetid, but also the specprod (fuji vs iron vs jura) and the survey, program, and healpix, then I'll much more easily be able to find the exact spectra you're working with.

The long-standing issues with the "smooth continuum" algorithm together with the line-fitting speed-ups facilitated by @jdbuhler, inspired me to build a brand new algorithm:

In essence, I now carry out an emission-line modeling step before continuum-fitting which considers both a narrow and broad+narrow line-model. A small subset of major lines are fit in "patches" (but with line-widths and line-centers still constrained across patches, using reasonable, physical assumptions), and the local continuum is taken to be a simple line. A conservative decision is then made about how much to mask all the lines, but particularly the broad Balmer lines.

Here's one of the optional QA figures from the first object in your list, iron/main/dark/9196/39633010890377403:

You can see that the initial fit of the Halpha+[NII] complex is quite good, which leads to the following line-mask (orange=emisison-line pixels; blue=local continuum pixels):

The final fit looks quite excellent, IMHO:

Comparing our respective fits to the H-alpha region, I find sigma=1558 km/s (FWHM=3670 km/s) for broad H-alpha (vs your FWHM=5475 km/s) and sigma=165 km/s (vs your 189 km/s estimate).

Some quick thoughts:

• A velocity width as large as yours seems excluded pretty strongly by the data. Are you taking into account the resolution matrix?
• Interestingly, your broad H-alpha line appears to be quite redshifted, centered nearly on [NII] 6584; what velocity shift do you find? By contrast, I find a blueshift of nearly 800 km/s.

Looking forward to hearing your thoughts and, in the meantime, I'll continue testing out the new algorithm.

[stephjuneau]

Hi @moustakas , it seems that the screenshot from Raga's post was for TARGETID=39633105035725300 (and not the first number she listed) as it resembles this iron version from the prospect link.

I note that the other two TARGETIDs (39633010890377403, 39627805847195825) including the one you fit above have very clear double-peaked narrow lines. Fitting them as a single component might slightly affect the BL fit but probably not too strongly because the BL components are quite prominent.

[moustakas]

Here's my updated fit for main/bright/9894/39633105035725300. I get a line-width of 3753 km/s, or FWHM=8838 km/s, a factor of 1.6 larger than what @Ragadeepika-Pucha reports.

Note that fitting multiple components to different lines (e.g., Halpha) is outside the scope of the current code, but functionality that I'm thinking of adding longer-term.

[Ragadeepika-Pucha]

Hi @moustakas @stephjuneau - I am sorry for the delay in getting back to you. I rechecked the fits from both guadalupe and iron, with and without smooth continuum correction from the existing FastSpecFit catalogs. Before running EmFit, I subtract the FastSpecFit continuum from the spectra. I am using v3.1 catalog for Guadalupe and v2.1 catalog for Iron.

TARGETID: 39633010890377403 {iron|guadalupe}/main/dark/9196/39633010890377403

This is the first case that you showed with detailed patches and masked pixels. In this case, the guadalupe and iron results are similar.

• Including smooth continuum gives an FWHM (broad Ha) ~ 1930 km/s and sigma (narrow Ha) ~ 170 km/s

• Not including smooth continuum gives an FWHM (broad Ha) ~ 3850 km/s and sigma (narrow Ha) ~ 160 km/s

  

This is similar to the FastSpecFit new estimates!

[Ragadeepika-Pucha]

TARGETID: 39633105035725300 {iron|guadalupe}/main/bright/9894/39633105035725300

This is the second target. In this case, the fits including the smooth continuum are different from guadalupe and iron. The one I posted in the first message is from guadalupe. I repeat that again here for comparison with iron.

• guadalupe with smooth continuum: FWHM (broad Ha) ~ 5475 km/s

  

• iron with smooth continuum: FWHM (broad Ha) ~ 6660 km/s

  

Not including the smooth continuum is definitely better versions for both guadalupe and iron, and looks similar to the new FastSpecFit results.

• guadalupe without smooth continuum: FWHM (broad Ha) ~ 8850 km/s

  

• iron without smooth continuum: FWHM (broad Ha) ~ 8830 km/s

  

It is really convincing that the EmFit results for broad Ha without smooth continuum are close to the estimates from the new code, showing that the new version fixes the smooth continuum issue. Thank you very much for taking the time to fix this issue. Can you please let me know if this new version also fixes the second issue I mentioned?