Adjust line width display scaling parameters

[mgalloy]

We expanded the line width display range, but it was not good. I reverted to the old parameters, but these need adjusting too.

@detoma says:

The value of 20 does not work for displaying linewidth. I am confused about what we actually save in the our linewidth. Is that the e-folding?

I think it would be best to plot the FWHM of the gaussian fit.

Can you ask Steve what that is that the pipeline computes and what should be the minimum expected value?

and

I think what we save is w = sqrt(2*sigma^2). If so, the display minimum of 30 is fine.

If w is sqrt(2)*sigma and assuming the filter has a FWHM of 0.138nm, the minimum value for 1074 is 33.6 for zero velocity and only considering thermal broadening. If so, I do not understand why our criteria for w is greater than 16. Without thermal broadening it would be 23, but that is always present. BUT I am not sure of any of these units. I am not even sure if the filter width of 0.138 is the FWHM.

We need some clarity from Steve.

[!NOTE] Time estimate: This is a trivial change, given the display parameters.

[bberkeyU]

@detoma I don't understand what you are asking, so I am probably not answering your question. But the line width calculation uses three independent .138nm wide measurements spaced .11 nm apart. So the whole line width sampling of the emission line goes from the blue side of the blue tuning to the red side of the red turning. ie .138/2 + .11 + .11 + .138/2 or a total of .358nm

I think you should be using this number .358 nm in the calculation of UCoMP line width response.

[bberkeyU]

This is a plot of what I think the filter is sampling with the dynamics files.

The green line is a Gaussians with an FWHM of .136nm. The blue, yellow, and red curves are Gaussians with FWHM of .138nm The blue and red curves are centered +/- .11nm from the yellow. On the Y axis, the tuning curves (yellow, red, and blue) have a max value of .9 to give some separation and better visibility between the green and yellow curves. You shouldn't take any meaning from the Y values along the curve, other than the relative shape.

[bberkeyU]

Sorry Guiuliana, I missunderstood the question. The sigma you are looking for is the spacing between tunings, not the filter width. So the 1074.7 sigma you are looking for is = .11nm. Adopting this value should reduce the velocities you are getting by a factor of 1.25.

In reply to:

I think what we save is w = sqrt(2sigma^2). If so, the display minimum of 30 is fine. The values we are writing in the fits files and pngs are the fit wc/wavelength, not w directly.

[detoma]

Let's chat today at the MLSO meeting. The confusion is about what we call "width" and publish in the dynamic file in km/s: Is it the FWHM, sigma, W or something else?

I believe it is W = sqrt(2sigma^2) while Maurice uses the FWHM.

To find the proper range for this quantity we need to know the filter width and line temperature. Steve seems to give the FWHM of the filter in his table not W, so we need to account for it.

[mgalloy]

1074 nm had a different display min/max (30 to 55) than the other wave regions (25 to 55). The new display min/max values are 50-90 for 1074 nm and 40-90 for other wave regions.

Should there be a single scaling range?

[mgalloy]

From @StevenTomczyk at the UCoMP meeting today: we should have different min/max display values by wave region. He can give theoretical value for each wave region.

[detoma]

Below are some numbers for both displaying and masking the line width.

Masking the line width W (where W is the e-folding W returned by the gaussian fit):

In this case we want to be conservative and not mask too much to make users happy. I used as minimum the filter line width W. If the line is narrower than this, something went wrong and the fit is not reliable. For the maximum, I used the W that includes the filter width, thermal broadening, and 80km/s velocity. These criteria should remove only bad pixels.

	min (km/s)	max(km/s)
1074.7	23	86
1079.8	24	86
789.4	16	84
706.2	13	85
637.3	11	83
530.3	TBD	TBD

Displaying the FWHM for the movies and png (this is the new width product FWHM=1.66511*W):

In this case I used as minimum the FWHM that includes the thermal broadening and filter width and 0km/s coronal velocity. For maximum, I used  the FWHM that includes the thermal broadening, filter width, and 30km/s velocity. Both are rounded to make it an integer number. The goal is to show variation in FWHM well.

	min (km/s)	max(km/s)
1074.7	54	74
1079.8	54	74
789.4	41	65
706.2	48	69
637.3	35	61
530.3	TBD	TBD

I checked them on Sep 1 2022 but I do not have the proper color table. We should test these values on a few days.

[detoma]

Please note that the display range is smaller than we had before, but by looking at the web data, I think it will work better to see variation in line width. The line-width images looked mostly blue/green before because the maximum was too high.

[mgalloy]

I don't see hardly anything in 706, but otherwise looks good to me. This is something we should check more thoroughly when we have processed the monthly test dates before the full reprocessing.

[detoma]

Very good. For 706, this has always been the case. 706 has very little signal in the intensity image because is the hottest line. The velocity and line-width are mostly zero. This is not an issue with the min and max.

[detoma]

The movies for the FWHM were too "reddish". I increased the maximum for the display of the FWHM using 35km/s.

Let's try these max values:

	max [km/s]
1074.7	79
1079.8	79
789.4	71
706.2	75
637.3	68

[detoma]

Thank you for testing the larger maximum values. The original values were better. The problem in 2021 and early 2022 is not the max but the line width itself that is not reliable.

For the final run use the maximum values from 5 days ago [74, 74, 65, 69, 61] and the python new color table.