Revive DIII-D get_n1_bradial_parameters

[yumouwei]

Implemented changes

• Reimplement D3DPhysicsMethods.get_n1_bradial_parameters. This method was previously moved to drafts/machine/d3d/physics.py in v0.8 (Add docstrings for modules/classes/methods #325) and later removed alongside all other draft scripts in v0.11 (Remove draft scripts #420).
• Create D3DPhysicsMethods.get_btor and use it in get_n1_bradial_parameters and get_n1rms.
• These new physics methods return n_equal_1_mode, n_equal_1_normalized (tested & XFAIL), and btor (not tested)

Notes on testing

• n_equal_1_mode and n_equal_1_normalized are both marked as XFAIL as all 4 testing shots fall within the range of shots where the raw signal data need to be retrieved from files previously stored on iris.
• I have checked these two signals with the last shot (177061) in the DISRUPTION_WARNING table and the outputs from this physics method match the data in the table.
• The outputs for shot 175552 (referenced in Nucl. Fusion 59 (2019) 096016) do not match the stored data in the DISRUPTION_WARNING table. I found out that these stored data match those from the legacy DUD system (fallback data source in the method's logic) instead of the ONFR system which is available for this shot.

Future TODO

• Implement get data from storage for shots between 156199--172430 and 176030--176912 (described in DIII-D unaccessible PTDATA pointnames  #261).

[gtrevisan]

@ZanderKeith, do you have some time to take a look?

[Copilot]

Pull request overview

Reintroduces DIII-D physics support for n=1 B-radial parameters by reimplementing D3DPhysicsMethods.get_n1_bradial_parameters and factoring out a reusable toroidal-field helper.

Changes:

• Added D3DPhysicsMethods.get_btor to retrieve/interpolate toroidal field (btor).
• Reimplemented get_n1_bradial_parameters to fetch ONFR/DUD bradial signals and compute normalized n=1 amplitude.
• Updated get_n1rms_parameters to use get_btor for normalization.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ZanderKeith]

Methods look correct physics-wise. Ran them for a few shots from our recent DIII-D campaign with significant MHD activity. Signals line up well with those in reviewplus.

I'd still like to know what dusbradial vs onsbradial mean (and perhaps have a comment noting the difference), but other than that looks good to me.

[gtrevisan]

I ran:

./scripts/disruption-errors.sh disruption_warning \
-m get_btor -m get_n1_bradial_parameters -m get_n1rms_parameters 

it "only" raised NotImplementedError... but for 10,797 shots out of 13,245 -- is this expected? at this scale?

[yumouwei]

I just checked the d3d disruption_warning table for the number of shots within the NotImplementedError ranges, and it matches exactly with what you got.

SELECT COUNT(DISTINCT SHOT) AS shot_count
FROM disruption_warning
WHERE (SHOT BETWEEN 156199 AND 172430)
   OR (SHOT BETWEEN 176030 AND 176912)

SELECT COUNT(DISTINCT SHOT) AS total_shot_count
FROM disruption_warning

> shot_count = 10,797 , total_shot_count = 13,245

So yeah it's a lot of shots.

[gtrevisan]

I'm not sure you want the tree closing operation in the finally block... I'd just put it as a last thing in the try block, otherwise you will raise exceptions if eg the tree does not exist.

[gtrevisan]

AFAICS we have custom recalc trees for 3,814 shots out of the total 16,232 in the specified range -- 12,418 are missing.

[yumouwei]

This is consistent with the docstring in the MATLAB script

disruption-py/DIII-D/get_n1_bradial_d3d.m

Lines 27 to 37 in 5d1a80d

	% 2019/04/05 - CR: This routine will not find any dusbradial or onsbradial
	% data in the "standard" (atlas) tree paths for certain
	% discharges. In September 2017, I went through the
	% existing 2014-2017 SQL database discharges and found
	% that 3814 shots were missing the bradial calculation.
	% B. Sammuli recomputed the missing bradial from the
	% existing ESLDs and stored the info as MDS data, in
	% tree structures for the specified shot numbers.
	% The actual data is stored in
	% /fusion/projects/disruption_warning/recalc_bradial
	% and /fusion/projects/codes/pcs/data/mdsdata/bradial

[yumouwei]

For that finally block, I was worrying if e.g. the tree.getNode statement raises an error and terminates this method, then this opened tree will never be closed. I don't know if the garbage collector does this automatically.

[gtrevisan]

does that exist for all shots in the range, or should we check for existence and possibly catch KeyErrors and reraise them as our upcoming custom exceptions?

[gtrevisan]

AFAICS these 4 shots (between 176030 and 176912) are not included in the .nc file:

• 176108 176209 176226 176227

[yumouwei]

We should raise an FetchDataError here to make it consistent with the behavior of xr.py.