Handle no rest wavelength

[mgalloy]

If no rest wavelength computed, don't give velocity. There should be a minimum number of pixels per hemisphere (east/west) to be able to compute each velocity.

Questions

• What should I do if the rest wavelength is not computable? Make doppler velocity all NaNs? Remove velocity extension from the file?

I tested several days and I think it is extremely unlikely that both the n_east and n_west is zero. If so, it is probably a bad file. I am coding it that if we are in this case, the velocity, line_width, and peak intensity should be set to all zero. We need to put a warning so we can measure how often it happens.

• What is the threshold for how many pixels are required per hemisphere?

1000 pixels. We need to run the test on the median synoptic to get a better handle on the number of pixels that are selected, especially for 1079 (see below).

[detoma]

For the cases when we have less than ~1000 pixels, we will use a value based on the daily synoptic files.

We will create a file with a rest wavelength as a function of time for all days we have a synoptic median file that we can use to derive the rest wavelength. We will use it to determine by interpolation the value of the rest wavelength for the image that does not have enough bright pixels. It is the best we can do on the days the corona is very dim.

We will test this approach in COMP and when we have a robust way to do this we should extend it to UCOMP because we have the same problem there.

[mgalloy]

Below is the output from comp_extract_restw for both 1074 nm and 1079 nm. Note: I put a 0 after n_all (in the 13th column) to make the format codes easier to deal with.

The columns are:

date, $
doppler_shift_0, velocity_0, line_width_0, peak_intensity_0, n_east0, n_west0, $
doppler_shift_1, velocity_1, line_width_1, peak_intensity_1, n_all, 0, $
doppler_shift_2, velocity_2, line_width_2, peak_intensity_2, n_east2, n_west2, $
doppler_shift_22, velocity_22, line_width_22, peak_intensity_22, n_east22, n_west22, $
doppler_shift_3, velocity_3, line_width_3, peak_intensity_3, n_east3, n_west3, $

comp.1074.restwvl-counts.mean.synoptic.txt

comp.1079.restwvl-counts.mean.synoptic.txt

[mgalloy]

I am getting 0 good indices in comp_compute_rest_wavelength from the following condition:

  threshold_condition = mask gt 0 $
                          and velocity ne 0 $
                          and velocity gt -30 $
                          and velocity lt 20 $
                          and intensity[*, *, 0] gt 0.5 $
                          and intensity[*, *, 1] gt rest_int_max $
                          and intensity[*, *, 2] gt 0.5 $
                          and intensity[*, *, 0] lt 60.0 $
                          and intensity[*, *, 1] lt 60.0 $
                          and intensity[*, *, 2] lt 60.0 $
                          and line_width gt 35.0 $
                          and line_width lt 120.0

I am doing some testing to determine which condition(s) are doing the restricting.

[detoma]

comp_extract_restwl.pro does not call comp_compute_rest_wavelength.pro. Are you getting zeros from comp_extract_restwl.pro? If so, the problem is not comp_compute_rest_wavelength. The condition above looks good. There was an inconsistency in the name of variable used and written in the fits. It is fixed. I will make a pull requests with the new files. I also changed comp_quick_invert.pro. Now it should be consistent with comp_l2_analytical.

[mgalloy]

OK, the above change (3b7c1d3) allows the comp_compute_rest_wavelength to find good pixels to find a rest wavelength. The change is to not add the rest wavelength, i.e., replacing

temp_velo = temp_data[*, *, 1] + rest

with

temp_velo = temp_data[*, *, 1]