Fix get_end_of_shot method in time_setting

[gtrevisan]

for some shots, no valid_indices are found in the _get_end_of_shot class method:

disruption-py/disruption_py/settings/time_setting.py

Lines 462 to 463 in e414215

	valid_indices = np.where((polarized_signal >= threshold) & (signal_time > 0.0))
	duration = signal_time[np.max(valid_indices)]

and thus we fail with:

ValueError: zero-size array to reduction operation maximum which has no identity

a couple of examples:

# on DIII-D
poetry run disruption-py 173927
# on EAST
poetry run disruption-py 59684

since this happens when setting up the timebase, such an exception is handled as critical and any further computation is impossible.

is there any fix? do these shots really deserve to be discarded?
otherwise we might just add a check on valid_indices and raise a user-friendlier exception.

[yumouwei]

For the ValueError, the only fix needed seems to be adding a pair of parentheses in L446. I'm more surprised how this hasn't cause any trouble before.

disruption-py/disruption_py/settings/time_setting.py

Lines 446 to 448 in 17589bf

	base_indices = np.where(signal_time <= 0.0)
	baseline = np.mean(signal[base_indices]) if len(base_indices) > 0 else 0
	signal -= baseline

D3D shot 173927 looks really weird though. My guess is that the ip timebase was shifted by ~7s, and the EFIT software automatically stopped at 10s which is why there's no EFIT data in the second half of the shot .

[yumouwei]

The other EAST shot looks just like a normal shot. It seems the only problem was caused by that np.where(signal_time<=0) line, as signal_time started at 0.03 for this shot.

[gtrevisan]

there are at least 3 cases in which, at a glance, I'd add a comma to unwind the tuple returned by np.where.
would you be able to check this out and fix all logic within that function? maybe in #439?

[gtrevisan]

closed with:

• Improve time settings #439