implement disruption time computation

[gtrevisan]

implement disruption time computation as internal method, as opposed to relying on the external disruptions table.

references on MFE WSs:

/usr/local/cmod/codes/mhd/magnetics/disruption_database/test_disrupt.pro
/home/granetz/Collaborations/DIII-D/disruption_database/test_for_disruption.m
/home/granetz/Collaborations/EAST/disruption_database/test_for_disruption.m
/home/granetz/Collaborations/KSTAR/disruption_warning_database/test_for_disruption_KSTAR.m

[yumouwei]

Comparing disruption time identification criteria

Criterion	CMOD	DIII-D	EAST	KSTAR
shot duration	> 0.1 s	> 0.5 s	> 0.6 s	> 0.3 s
abs(Ip_max)	> 0.1 MA	> 0.1 MA	> 0.2 MA	> 0.2 MA
Ip0/Ip_max	> 0.33	> 0.33	> 0.33	> 0.33
Ip0/max_dIdt	< 0.050 s 1	< 0.050 s	< 0.050 s	< 0.050 s
|Ip_final| , within # of t_dis	< 50 kA, 0.015s	< 100 kA, 0.015s	< 100 kA, 0.015s	< 100 kA, 0.015s
abs(Ip0)		> 0.1 MA	> 0.1 MA	> 0.1 MA

¹ Given as -Ipdot/Ip > 20 (current decay time < 0.050 s)

Criteria

1. shot duration > # s -- reject very short shots
2. abs(Ip_max) > # MA -- reject very low current shots
3. Ip0/Ip_max > # -- reject shots that disrupt late in current ramp down
4. Ip0/max_dIdt < # s -- reject shots with relatively slow current decay
5. |Ip_final| < # kA within # s -- reject minor disruptions
6. abs(Ip0) > # A -- reject very low current disruptions

[yumouwei]

I checked Bob's test_for_disruption_d3d.m. It agrees with the disruptions table that 166177 and 166253 are considered as non-disruptive shots (i.e. the function cannot find a t_disrupt that satisfies all of the testing criteria), despite these two shots having the runtag=DIS EFIT trees and contrary to what was mentioned by Bob during the disruption-py meeting a couple weeks ago.

I'm also confused by the logic of the function. It looks like it is not trying to identify the ip spike prior to the current quench. Instead the identified points seem to be the point with the max gradient in the middle of the current quench (see two plots below). This is different from what I expected and have seen in previous disruption prediction studies, and I wonder if this was intentional.

Update

According to the comments in test_for_disruption_d3d.m, finding the max gradient point as t_disrupt seems to be intentional.

% Now compute dI/dt during the latter part of the discharge. If it's
% faster than the specified limit, then this shot is a candidate for being
% declared a disruption, and the time of maximum abs(dI/dt) is the
% disruption time.

[github-actions]

This issue has been open for 3 months with no activity.

[github-actions]

This issue has been open for 3 months with no activity.

[github-actions]

This issue has been open for 3 months with no activity.

[github-actions]

This issue has been open for 3 months with no activity.