Add C-Mod Thermal Quench Labeler

[hwietfeldt]

Overview

I created a C-Mod physics method get_thermal_quench_onset_time() that labels the onset of the thermal quench (TQ) for a given shot (NaN for non-disruptive shots) using a vertical SXR array. The TQ time is returned as a column with identical values for each time slice. I used SXR instead of ECE because ECE is less reliable (especially for shots at low Bt) and because the SXR arrays can track the plasma core during a hot VDE. I used a vertical array because the horizontal array wasn't working for most 2005 shots. For 100 manually labeled flattop TQ onsets, this method labeled the onset within 1 ms of the manual label in 90% of cases. For the remaining 10%, the automated TQ label is usually still a more accurate disruption time metric compared to the current t_disrupt based on the maximum of |dIp/dt|. This method has also worked well in my UFO labeling workflow. I have not tested this method during ramp-up or ramp-down

Steps of Method

1. Read Ip and SXR chords from MDSplus
2. Subtract background from each SXR chord
3. Discard bad chords dominated by noise by removing chords with low autocorrelation.
4. Filter the SXR chords using a non-causal Butterworth low pass filter.
   This helps to smooth transient, positive SXR spikes during the TQ, which I attribute to recombination radiation. There is a tradeoff when choosing the cutoff frequency between maintaining decent temporal resolution and removing the recombination spikes. I found a cutoff frequency of 1 kHz works best.
5. Select the SXR chord viewing the core by taking the maximum of SXR across all chords for each time slice.
6. Search for the onset of the CQ based on Ip and t_disrupt.
   This enables us to search for the TQ in a small time window prior to the CQ onset. We need a small search window to avoid labeling sawtooth crashes as the TQ while enabling us to label the TQ for shots with long CQs (see shots 1050311013, 1050802017).
7. Find the midpoint of the TQ by finding the minimum of dSXR/dt within a 5 ms window prior to the CQ onset.
8. Find the TQ onset within a 0.5 ms window prior to the TQ midpoint.
   Note that almost all TQs have a duration less than 1 ms.

Case that works well

We correctly label the TQ onset, which is around 7 ms prior to $t_{disrupt}$. The $T_{e0}$ signal is junk because ECE was not working on this shot, which motivates the use of SXR for TQ labeling on C-Mod.

Results from Testing

I tested this method on 100 disruptive shots for which I manually labeled the TQ onset and end using ECE, SXR, H alpha, and other diagnostics. The plot below compared the error in the automated TQ onset vs the error we currently get when we use t_disrupt as the onset of the disruption compared to my manually labeled TQ onsets. From the y-values, we see that the automated TQ labeling routine labeled the TQ onset within 0.5 ms of the actual onset for most shots. As guaranteed by the algorithm, no automated TQ labels are later than t_disrupt. There are a several labels that are early or late by more than a ms. In these cases, there may be some ambiguity in the TQ onset (multiple partial thermal collapses), or there were strong recombination spikes. The search windows and filtering cutoff frequency have tradeoffs, so I was not able to eliminate these outliers. Nevertheless, I believe that the TQ labels provide a much more accurate metric of the onset time of the disruption for many of our workflows compared to the current t_disrupt.

Most early label

In this shot, the TQ time is automatically labeled around 0.511 s, which is at the onset of a sawtooth or small thermal collapse. I manually labeled the TQ onset around 0.514 s, which is the main thermal quench according to ECE (second panel) and the Ip spike (first panel). Again, I don't think that is 3 ms early label for the TQ is too bad. Using t_disrupt may be worse for some workflows as it is clearly after the disruption onset. If using t_disrupt, the user risks leaking disruption information into their disruption prediction model.

Most late label

Here a very strong SXR recombination spike coupled with a long delay between the Ip spike and when Ip crashes causes a late label. The TQ onset is not much better than t_disrupt, but it's also not worse.

Timing

I timed various steps of the TQ labeler. It can be slow for disruptive shots from 2012-2016. Note that for 2005 shots, the SXR was digitized at 5 kHz, not 250 kHz, so the algorithm is faster. Reading all 38 chords from MDSplus is a bottleneck. I tried using MDSplus's getMany() function to read the chords in one batch call; however, that was slower. For non-disruptive shots, the algorithm is fast because it immediately returns NaNs if t_disrupt is 0.

Timing averages for 2005 shots
Reading MDSplus: 0.20789 s
Calculating autocorrelation: 0.0264536 s
Butterworth Filter: 0.00573944 s
Finding TQ: 0.000120203 s
Total: 0.242485 s

Timing averages for 2012-2016 shots
Reading MDSplus: 3.87387 s
Calculating autocorrelation: 0.0920277 s
Butterworth Filter: 0.194109 s
Finding TQ: 0.00131993 s
Total: 4.16501 s

[hwietfeldt]

@yumouwei @AlexSaperstein

Once we are satisfied with the method and testing, I'll clean up the method and turn the draft PR into a normal PR.

[yumouwei]

I refactored the lines for retrieving the SXR chords and doing the autocorrelation check. Can you double-check and make sure this method still behaves the same?

[yumouwei]

@hwietfeldt can you fill in these references?

[hwietfeldt]

I reproduced the previous test results with your new commits (see the below plot). I'll add the references soon.

[hwietfeldt]

Note the similar plot from the initial comment on the PR was from a slightly outdated version, so the results of the 'Old' are a bit better than the test results of the plot in the initial comment. 'Old' refers to the test results of the latest version prior to William's commits, and 'New' is using the version after William's commits. They agree perfectly, so the method behaves the same before and after William's refactoring.

[yumouwei]

@hwietfeldt can you put this plot and the comments in the main thread? This comment thread will be collapsed once we hit "resolve conversation"

[AlexSaperstein]

Things look good to me. I checked the TQ labels against the manual labels i did for the 100 flattop shots from ramping analysis and the labels for the most part look much better than the automated t_disrupt (CQ time) labels

The caveat is that within this dataset there are more examples where the TQ is labeled more than 1 ms beyond the manual label (31 out of the 100 cases). However, after manually inspecting several of the outlier cases, it seems that many of their manual labels were maybe just a little too early, with the automatic TQ label appearing more appropriate.

As a result, it looks to me like these labels are pretty good!

[hwietfeldt]

I reproduced the previous test results with William's new commits. Note the similar plot from the initial comment on the PR was from a slightly outdated version, so the results of the 'Old' are a bit better than the test results of the plot in the initial comment. 'Old' refers to the test results of the latest version prior to William's commits, and 'New' is using the version after William's commits. They agree perfectly, so the method behaves the same before and after William's refactoring.

[hwietfeldt]

I added the references and a sentence describing the accuracy of the labeler to the docstring. I also merged the latest few commits from dev. I reran my testing scripts, reproducing the above plot, this time with 'Old' being the results after William's commits and 'New' being after merging the latest commits from dev, so the labeler works as before.