Revive DIII-D get_n1_bradial_parameters by yumouwei · Pull Request #500 · MIT-PSFC/disruption-py

yumouwei · 2025-12-18T23:06:14Z

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 · 2026-04-21T16:04:10Z

+        b_tor = D3DPhysicsMethods.get_btor(params)["btor"]
+        if np.isnan(b_tor).all():
+            params.logger.warning(
+                "Failed to get b_tor signal to compute n_equal_1_normalized"


I think the name of the physics method will be attached to error log by the framework, so this might be redundant...
put an intentional error somewhere to try it out!

It looks like only the shot number is automatically tagged to the error log if I intentionally poke an error. This applies to the comment on the other method as well

08:49:57.574 [WARNING] #201927 | Failed to get b_tor signal to compute n_equal_1_normalized
08:49:57.580 [WARNING] #201927 | Failed to get b_tor signal to compute n1rms_normalized

because you are writing that yourself, but if you raise eg a CalculationError you will see the physics method name as well.

gtrevisan · 2026-04-21T16:05:02Z

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

gtrevisan · 2026-04-21T19:32:10Z

+            b_tor, t_b_tor = params.data_conn.get_data_with_dims(
+                f"ptdata('bt', {params.shot_id})"
+            )  # [ms], [T]
+        except mdsExceptions.MdsException as e:


I'm not sure we'd need this.

Do you mean removing this try-except block? If so then an error in this get_btor method would cause other methods that call get_btor (i.e. get_n1_bradial_parameters and get_n1rms_parameters) to raise an error and return all nans as well. I can avoid this by adding try-except blocks in those methods if that's a better way to do this.

gtrevisan · 2026-04-21T19:32:47Z

+                f"ptdata('onsbradial', {params.shot_id})",
+            )  # [G], [ms]
+        except mdsExceptions.MdsException:
+            try:


this fallback would deserve at least a DEBUG statement, if not a warning!

The fallback does raise a VERBOSE statement if it successfully gets data from DUSBRADIAL. The use of VERBOSE is consistent with the fallback in CMOD get_v_loop

disruption-py/disruption_py/machine/d3d/physics.py

Lines 983 to 990 in 4e35955

try:

# Fallback: get data from the legacy DUD system

n_equal_1_mode, t_n1 = params.data_conn.get_data_with_dims(

f"ptdata('dusbradial', {params.shot_id})",

) # [G], [ms]

params.logger.verbose(

"n_equal_1_mode: Failed to get ONSBRADIAL signal. Use DUSBRADIAL instead."

)

disruption-py/disruption_py/machine/cmod/physics.py

Lines 551 to 557 in 4e35955

except mdsExceptions.TreeException:

params.logger.verbose(

r"v_loop: Failed to get \top.mflux:v0 data. Use \efit_aeqdsk:vloopt instead."

)

v_loop, v_loop_time = params.data_conn.get_data_with_dims(

r"\efit_aeqdsk:vloopt", tree_name="_efit_tree"

) # [V], [s]

I missed that. but yeah, you should log to debug before attempting the fallback, otherwise that might never get logged.

gtrevisan · 2026-04-21T19:33:17Z

+                    "n_equal_1_mode: Failed to get ONSBRADIAL signal. Use DUSBRADIAL instead."
+                )
+            except mdsExceptions.MdsException:
+                params.logger.warning(


this could be a CalculationError which would then downplayed as a warning by the framework.

gtrevisan · 2026-04-21T19:34:13Z

-        except mdsExceptions.MdsException as e:
+        b_tor = D3DPhysicsMethods.get_btor(params)["btor"]
+        if np.isnan(b_tor).all():
            params.logger.warning(


you might want to raise another CalculationError, here, and remember that shot number and physics method should be tagged on by the framework!

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.

Copilot · 2026-04-21T19:45:05Z

+            raise NotImplementedError
+        if 176030 <= params.shot_id <= 176912:
+            # TODO: load data from NetCDF file
+            raise NotImplementedError


These known shot ranges currently raise NotImplementedError. The runner treats this as an ERROR (not a WARNING), which will generate noisy error logs for an expected/known data gap. Consider returning all-NaN outputs with a warning log, or raising CalculationError with an explanatory message so it’s handled at WARNING level.

Suggested change

raise NotImplementedError

if 176030 <= params.shot_id <= 176912:

# TODO: load data from NetCDF file

raise NotImplementedError

params.logger.warning(

"n_equal_1_mode: Bradial data is unavailable for shot range "

"156199-172430; returning NaN outputs until custom tree loading "

"is implemented."

)

nan_output = np.full_like(params.times, np.nan, dtype=float)

return {

"n_equal_1_mode": nan_output,

"n_equal_1_normalized": nan_output.copy(),

}

if 176030 <= params.shot_id <= 176912:

# TODO: load data from NetCDF file

params.logger.warning(

"n_equal_1_mode: Bradial data is unavailable for shot range "

"176030-176912; returning NaN outputs until NetCDF loading "

"is implemented."

)

nan_output = np.full_like(params.times, np.nan, dtype=float)

return {

"n_equal_1_mode": nan_output,

"n_equal_1_normalized": nan_output.copy(),

}

ZanderKeith · 2026-04-23T22:19:30Z

+            try:
+                # Fallback: get data from the legacy DUD system
+                n_equal_1_mode, t_n1 = params.data_conn.get_data_with_dims(
+                    f"ptdata('dusbradial', {params.shot_id})",


What is the difference between dusbradial and onsbradial? What do these signals mean / which coils are they coming from?

Towards the end of the shot they are usually in agreement but at the start they can be very different.

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 changed the title ~~Revive D3D get_n1_bradial_parameters~~ Revive DIII-D get_n1_bradial_parameters Feb 3, 2026

gtrevisan added the machine: DIII-D Related to the DIII-D tokamak label Feb 3, 2026

gtrevisan marked this pull request as draft February 6, 2026 14:59

yumouwei added 6 commits March 11, 2026 10:46

Revamp d3d.get_n1_bradial_parameters method

2adc1d3

Test method on d3d server, then made improvements

c25e4fc

Move get_btor to its own physics method

ba7b1e7

Fix n_equal_1_mode unit

562e27e

Add docstrings

fbd4b24

Add PR reference

19f6fd6

yumouwei force-pushed the wei/d3d-onsbradial branch from 1107210 to 19f6fd6 Compare March 11, 2026 14:46

yumouwei added 2 commits April 21, 2026 08:14

Merge branch 'dev' into wei/d3d-onsbradial

a6665f6

Change mds_conn to data_conn

4e35955

yumouwei marked this pull request as ready for review April 21, 2026 15:46

gtrevisan reviewed Apr 21, 2026

View reviewed changes

gtrevisan requested a review from ZanderKeith April 21, 2026 16:04

gtrevisan reviewed Apr 21, 2026

View reviewed changes

Comment thread disruption_py/machine/d3d/physics.py

gtrevisan requested a review from Copilot April 21, 2026 19:39

Copilot started reviewing on behalf of gtrevisan April 21, 2026 19:40 View session

Copilot AI reviewed Apr 21, 2026

View reviewed changes

ZanderKeith reviewed Apr 23, 2026

View reviewed changes

	try:
	# Fallback: get data from the legacy DUD system
	n_equal_1_mode, t_n1 = params.data_conn.get_data_with_dims(
	f"ptdata('dusbradial', {params.shot_id})",
	) # [G], [ms]
	params.logger.verbose(
	"n_equal_1_mode: Failed to get ONSBRADIAL signal. Use DUSBRADIAL instead."
	)

	except mdsExceptions.TreeException:
	params.logger.verbose(
	r"v_loop: Failed to get \top.mflux:v0 data. Use \efit_aeqdsk:vloopt instead."
	)
	v_loop, v_loop_time = params.data_conn.get_data_with_dims(
	r"\efit_aeqdsk:vloopt", tree_name="_efit_tree"
	) # [V], [s]

-            raise NotImplementedError
-        if 176030 <= params.shot_id <= 176912:
-            # TODO: load data from NetCDF file
-            raise NotImplementedError
+            params.logger.warning(
+                "n_equal_1_mode: Bradial data is unavailable for shot range "
+                "156199-172430; returning NaN outputs until custom tree loading "
+                "is implemented."
+            )
+            nan_output = np.full_like(params.times, np.nan, dtype=float)
+            return {
+                "n_equal_1_mode": nan_output,
+                "n_equal_1_normalized": nan_output.copy(),
+            }
+        if 176030 <= params.shot_id <= 176912:
+            # TODO: load data from NetCDF file
+            params.logger.warning(
+                "n_equal_1_mode: Bradial data is unavailable for shot range "
+                "176030-176912; returning NaN outputs until NetCDF loading "
+                "is implemented."
+            )
+            nan_output = np.full_like(params.times, np.nan, dtype=float)
+            return {
+                "n_equal_1_mode": nan_output,
+                "n_equal_1_normalized": nan_output.copy(),
+            }

Conversation

yumouwei commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Implemented changes

Notes on testing

Future TODO

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gtrevisan commented Apr 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gtrevisan Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gtrevisan Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ZanderKeith left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

yumouwei commented Dec 18, 2025 •

edited

Loading

gtrevisan Apr 21, 2026 •

edited

Loading

gtrevisan Apr 22, 2026 •

edited

Loading