Possibly mislabeled shots in d3d_*_100.txt?

[rkube]

Hi, going through the D3D logbook it seems some shots that have been labelled disruptive in d3d_disrupt_100.txt appear to have died from other reasons than a disruption.

Most of the shots have duration less than 1s and would probably be removed by pre-processing. But it would be good to take a closer look to avoid mis-labeling.

Shots I found suspicious, based on short shot duration: 167515, 167548, 168439, 168440, 168441, 168442, 168443, 168444, 168450, 168483, 168484, 168485, 168486, 168487, 168488, 168490, 168491, 168500

168442

From the logbook - Died due to a presumed carbon dust mote. Corresponding logbook entry:

Jan 20 2017 10:34:32:393AM |  
-- | --
Repeat. Add ECH -40->20msResult: Good. Got 3 gyros. ~ 800 kA up to 800ms before died. Density control good. maybe UFO?

168442 | hyatt | PHYSICS_OPERATOR | Jan 20 2017 10:59:31:757AM |  
-- | -- | -- | -- | --
RepeatResult: OK, a much better pulse. Lasts to appx 800 ms, enough for lots ofEFIT01 slices. Still dies of density skyrocketing, but this time due to apresumed carbon dust mote. Oxy is relatively loww considering the no-bakecondition. We do have a lot of carbon but that's expected after tielinstallation (SAS). We are getting some gyros' short pulses at t=0, but no auxheating after that.

[168442](http://nomos.gat.com/DIII-D/physics/summaries/summary.php?run=20170120#168442) hyatt   PHYSICS_OPERATOR    Jan 20 2017 10:59:31:757AM  
Repeat

Result: OK, a much better pulse. Lasts to appx 800 ms, enough for lots of
EFIT01 slices. Still dies of density skyrocketing, but this time due to a
presumed carbon dust mote. Oxy is relatively loww considering the no-bake
condition. We do have a lot of carbon but that's expected after tiel
installation (SAS). We are getting some gyros' short pulses at t=0, but no aux
heating after that.

168443

Logbook entry:

168443 | eidietis | PHYSICS_OPERATOR | Jan 20 2017 10:57:17:530AM |  
-- | -- | -- | -- | --
Repeat.3 gyros.Result: Once again died at ~ 0.75s. Density is staying well below target... why?realized no EFC. Appear to lock.

[168443](http://nomos.gat.com/DIII-D/physics/summaries/summary.php?run=20170120#168443) eidietis    PHYSICS_OPERATOR    Jan 20 2017 10:57:17:530AM  
Repeat.
3 gyros.

Result: Once again died at ~ 0.75s. Density is staying well below target... why?realized no EFC. Appear to lock.

168443 | eidietis | PHYSICS_OPERATOR | Jan 20 2017 11:10:06:013AM |  
-- | -- | -- | -- | --
Turn on Icoil EFCResult: No plasma. Machine operator error caused T1/T2 to kill shot early.

[168443](http://nomos.gat.com/DIII-D/physics/summaries/summary.php?run=20170120#168443) eidietis    PHYSICS_OPERATOR    Jan 20 2017 11:10:06:013AM  
Turn on Icoil EFC

Result: No plasma. Machine operator error caused T1/T2 to kill shot early.

168443 | hyatt | PHYSICS_OPERATOR | Jan 20 2017 11:15:17:610AM |  
-- | -- | -- | -- | --
RepeatResult: OK, but a slight step back. Lasts to appx 800 ms, enough for lots ofEFIT01 slices. Still dies of density skyrocketing, but this time due to apresumed carbon dust mote. Oxy is relatively loww considering the no-bakecondition. We do have a lot of carbon but that's expected after tielinstallation (SAS). We are getting some gyros' short pulses at t=0, but no auxheating after that.

[168443](http://nomos.gat.com/DIII-D/physics/summaries/summary.php?run=20170120#168443) hyatt   PHYSICS_OPERATOR    Jan 20 2017 11:15:17:610AM  
Repeat

Result: OK, but a slight step back. Lasts to appx 800 ms, enough for lots of
EFIT01 slices. Still dies of density skyrocketing, but this time due to a
presumed carbon dust mote. Oxy is relatively loww considering the no-bake
condition. We do have a lot of carbon but that's expected after tiel
installation (SAS). We are getting some gyros' short pulses at t=0, but no aux
heating after that.

[rkube]

Going through the 8am presentations, I found that there were no experiments scheduled on 1/20/2017. https://diii-d.gat.com/DIII-D/805/#2017_02

It appears that the shots above just happened to be in a maintenance period.

[felker]

I will remove 168440, 168441, 168444 (nondisruptive) and 168442, 168443 (disruptive). That would still leave 168445 - 168449 in that set of 16844*, all marked as disruptive. Can we confirm that they did not occur during a maintenance period?

❯ grep -nri "16844" d3d_clear.txt d3d_disrupt.txt
d3d_clear.txt:74226:168440   -1.000000
d3d_clear.txt:74227:168441   -1.000000
d3d_clear.txt:74228:168444   -1.000000
d3d_disrupt.txt:17243:168442   0.847500
d3d_disrupt.txt:17244:168443   0.626500
d3d_disrupt.txt:17245:168445   2.576500
d3d_disrupt.txt:17246:168446   1.405500
d3d_disrupt.txt:17247:168447   1.776500
d3d_disrupt.txt:17248:168448   2.082500
d3d_disrupt.txt:17249:168449   1.831000

• [ ] Add check that the other short shots you listed get removed by preprocessing:

167515, 167548, 168439, 168450, 168483, 168484, 168485, 168486, 168487, 168488, 168490, 168491, 168500

[rkube]

Continuing to work through the dataset it appears that 167574 is labelled clear while the logbook says it disrupts after 900ms. I think it would be worth-while to go through the d3d-100 dataset shot by shot.