Flat quality control

[bberkeyU]

@mgalloy @detoma @jburkepile
After our meta-discussion last week, we noticed an unexpectedly large change in the FLATDN values for the example day (20220202). The good news is that 20220202 was the worst day in 2022 for changes in the median flat value over time (assuming nuc, exposure time, and gain didn't change, and SGSSUMV value was above 6 (guiding)). As far as I can tell, the bad news is that we do not do any quality control on our flats, so flats with weird values and potentially wrong NUCs may have been used for the last processing.

Below are daily plots of the median flat values pulled from the level1/YYYYMMDD.ucomp.1074.flat.fts in the UCoMP process directory. The median was computed in an annulus that represents most of the high signal region of a coronal image and does not include the regions in the corner of the image or under the occulter.

I only selected 1074 flats with tcam onband, high gain, exposure time of 80 ms, and SGSDIMV > 6. Selecting ONBAND=tcam selected only half of the data. This was done to make the plots a little less confusing, as onband=tcam and onband=rcam flats have similar but slightly different values. The other criteria only clean up a couple of edge cases, mostly related to testing.

Looking at all the Tcam flats, we can see a general trend that the median values are clustered around three values. The ~320-350 count cluster is the NUC=Offset +gain that we ran with from late February to November. I think the other two clusters are NUC=normal with slight changes to the field lens and lyot stop.

In addition to these general trends, we can see that the flat value also varies with the wavelength (and, to a lesser extent, modulation) as the sawtooth signature in the data.

There is also a magenta line 2022-02-23, which jumps from the high cluster to the low cluster when we switch NUCS 1/2 through the day.

Focusing on just the days in which the flat values change by more than 60dn (and ignoring the NUC change on 2022-02-23) it looks like we have multiple flats taken when we weren't well pointed at the sun or something else was reducing the light to near background levels.

I have been playing around with various methods of detecting bad flats, and so far, the best I can come up with is something like making sure SGSDIMV > 6 (which won't always work if the SGS keywords aren't working or you are looking at 2021 data when the SGS values were lower). And a check that the flat values dont drop by 100+ from the nominal median (for that epoch of UCoMP configuration).

[bberkeyU]

To clarify, the data for the plots above was computed as median(Flat_L0/Flat_NUMSUM). I used the RAWFILES keywords in the level1/YYYYMMDD.ucomp.1074.flat.fts files to create a list of L0 Flats to open. I did not use the image data from the Level1 flat file, as these files have like frames combined and do not have the RCAM/TCAM NUC values keywords.

The masking used an annulus centered in the middle of the array with an inner radius of 375 pixels and an outer radius of 600 pixels. It also included a 150-pixel-wide notch around the occulter post. These choices are oversized for the occulter and post to the point that I think they block both for all the 2022 data. This may not be the best mask for a flat, but I think it should help give a more consistent median since it avoids the solar signage bleed-through near the middle of the array as well as the dark corners of the array.

[bberkeyU]

789 shows similar results. We still have the high and low NUC grouping.

We are also seeing the days with bad flats having dropped a few frames down below the collection. The most significant difference is for 789, the drop is ~40dn instead of 100-150dn.