Adding p_oh method for MAST

[AlexSaperstein]

Adding Ohmic heating power feature/method for the MAST tokamak.

The method used is based on that used for the same calculation for C-Mod, which uses Ip, li(3), and vloop.

• MAST has multiple vloop calculations available. The dynamics vloop was used in this calculation over the static calculations, as it allows for the motion of the LCFS, making it strictly more accurate.
• This method, that C-Mod also currently uses, does not consider the Ip*dL/dt contribution to V_inductive, which gets subtracted from Vloop to reconstruct V_resistive. This implies that the p_oh calculation may be less accurate during periods of fast li(3) changes, like during temperature profile collapses. A correction to p_oh that properly accounts for this term is in development.

[gtrevisan]

great, thank you, Alex!

it looks like you branched off an old version of dev, though, so you might want to rebase off the current one -- probably better, just reapply your code to the current dev.

[gtrevisan]

furthermore, please try and add the appropriate attributes in:

• https://github.com/MIT-PSFC/disruption-py/blob/dev/disruption_py/machine/mast/config.toml

finally, I'll try running at scale for you in order to detect any outliers that might require more function logic... I'll report back here.

[gtrevisan]

after ~1,000 shots I've only got errors like this one:

[ ERROR ] #11812 | get_ohmic_parameters: ValueError('x and y arrays must be equal in length along interpolation axis.')

the debug log does not show sizes, but I imagine you'll have some NaNs or 0- or 1-long arrays in there.

[AlexSaperstein]

it looks like you branched off an old version of dev, though, so you might want to rebase off the current one -- probably better, just reapply your code to the current dev.

Is there a way to reapply to the current dev while retaining this PR?

[gtrevisan]

I'd remove your local branch, branch off again from the latest dev, then copy back the file and continue editing.
finally, push-force a new commit to this branch.

[AlexSaperstein]

I'd remove your local branch, branch off again from the latest dev, then copy back the file and continue editing. finally, push-force a new commit to this branch.

I just did this, and fixed the other stuff as well

[gtrevisan]

furthermore, please try and add the appropriate attributes in:

* https://github.com/MIT-PSFC/disruption-py/blob/dev/disruption_py/machine/mast/config.toml

finally, I'll try running at scale for you in order to detect any outliers that might require more function logic... I'll report back here.

&

after ~1,000 shots I've only got errors like this one:

[ ERROR ] #11812 | get_ohmic_parameters: ValueError('x and y arrays must be equal in length along interpolation axis.')

the debug log does not show sizes, but I imagine you'll have some NaNs or 0- or 1-long arrays in there.

[AlexSaperstein]

after ~1,000 shots I've only got errors like this one:

[ ERROR ] #11812 | get_ohmic_parameters: ValueError('x and y arrays must be equal in length along interpolation axis.')

the debug log does not show sizes, but I imagine you'll have some NaNs or 0- or 1-long arrays in there.

Checking this shot specifically, it does look like one of the signals (vloop) is only 1-long.

What should we do for these instances? How often is this error showing up?

[gtrevisan]

fixing that error requires further thought -- it might be our xarray backend returning NaNs instead of raising KeyError -- so all good for now!

[Copilot]

Pull request overview

Adds support for computing and exposing total Ohmic heating power (p_oh) for the MAST tokamak in the physics methods layer, and registers the new attribute in the MAST configuration.

Changes:

• Add MastPhysicsMethods.get_ohmic_parameters() physics method that computes p_oh from loop voltage, inductance, and plasma current.
• Import and use causal_boxcar_smooth to smooth dI_p/dt before computing inductive voltage.
• Register mast.physics.attributes.p_oh in config.toml with units and IMAS mapping.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
disruption_py/machine/mast/physics.py	Introduces new p_oh physics method and required math utility import.
disruption_py/machine/mast/config.toml	Adds p_oh attribute metadata (description/units/IMAS path).

---

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

[gtrevisan]

LGTM. waiting for @yumouwei's review... or maybe @zapatace's?

[yumouwei]

@AlexSaperstein can you put a few bullet points in the PR description to describe how you implemented this method? e.g. you can mention the distinction between static vs dynamic vloop, and incorporating only the L*dI/dt term in the calculation. Other than that this PR looks good and should be ready to go.

[AlexSaperstein]

The p_oh signals were coming out very noisy. I found that this was because the dip_smoothed signal was still very noisy as well, despite having the same smoothing settings as those used for C-Mod. The reason why dip is noisier for MAST than C-Mod is that the time-base for Ip that the MAST database provides is much slower than what we have for C-Mod. So when we smooth over the same 6 points, the MAST signal remains noisier.

To minimize this noise, while also keeping delays acceptable, the smoothing window for the MAST calc of p_oh was updated from 6-->30. Comparing the 6-point and 30-point smoothed p_oh signals (below), this larger window increases the delay to ~10ms.

This ~10ms delay should be acceptable for the time being, and is certainly more beneficial than having too noisy of a p_oh signal.

[gtrevisan]

will we need to tweak this parameter further?
maybe we should make it a configuration.
@yumouwei your call!

in any case, @AlexSaperstein, I'd imagine you might want to update your len check to the same number, right?

[AlexSaperstein]

will we need to tweak this parameter further? maybe we should make it a configuration. @yumouwei your call!

in any case, @AlexSaperstein, I'd imagine you might want to update your len check to the same number, right?

It is something we could tweak in the future, but it's not something that I think we have to do

[yumouwei]

I agree with Alex. LTGM and see if there's any problem with the computed p_oh, then we can adjust the filtering accordingly.

[gtrevisan]

apologies for the conflicts, but please merge dev so as to pull in changes from:

• Simplify calls to data getters #555
• Introduce CustomErrors and DataErrors #554

[AlexSaperstein]

apologies for the conflicts, but please merge dev so as to pull in changes from:

* [Simplify calls to data getters #555](https://github.com/MIT-PSFC/disruption-py/pull/555)

* [Introduce CustomErrors and DataErrors #554](https://github.com/MIT-PSFC/disruption-py/pull/554)

It's all ready