Improve CMOD ohmic power computation

[yumouwei]

Previous discussion

• Smoothing v_loop and p_oh #406

Implemented changes

• Replace the boxcar smoothing function for calculating dip_smoothed with the newly added causal_boxcar_smooth function.
• Use the same causal_boxcar_smooth function to smooth the noisy v_loop signal (from \analysis::top.mflux:v0).
  • For both dip_smoothed and v_loop I use 6-point boxcar smoothing which introduces a delay of about 0.5 ms observed at the end of the shot (see figures in the issue). I believe this amount of delay is tolerable since we are going to rerun EFIT with 1 ms interval.
• Replace all negative values of the computed p_oh to 0.
  • This isn't the ideal approach. I have also considered removing these data points and interpolate them from the nearby points. However, the nearby points aren't necessarily reliable either especially prior to a disruption where we observe higher level of fluctuation in magnetic signals due to plasma dynamics or noise. To me this is unavoidable since we are inferring the ohmic power through measurements on the plasma instead of the central stack voltage -- perhaps @granetz can comment on this.

Note

• I have not removed the plotting functions for comparing the raw & filtered signals! I have removed the plotting functions. The previous version with the plotting functions are now moved to a new branch called wei/improve-get-ohmic-plotting. @AlexSaperstein please take a look using a couple other shots and make sure the levels of noise and delay are acceptable.

TODO:

• 🚨rebase🚨 to origin/dev in order to modify the docstring.
• The previous (non-causal) smooth function is also used in the EAST branch. I'll update those methods in a separate PR.

[granetz]

@yumouwei @gtrevisan @hwietfeldt @AlexSaperstein The voltage signals for the C-Mod CS (which includes OH1, OH2U, & OH2L power supplies), and the #of turns in each of those solenoids is in the C-Mod engineering subtree for every shot, so in principle the CS stack voltage can be obtained. Of course, this ignores any effect of the vacuum vessel. But you could start by comparing the CS stack voltage against the derived loop voltage.

[hwietfeldt]

Hey, I wanted to add myself to the conversation since I've learned a few things about Vloop (including \efit_aeqdsk:vloopt, which is currently used in case reading \mflux:v0 results in an error):

• From Bob: \mflux:v0 is not a measured signal. It’s from the flux loops data projected into the core (some linear combination of flux loops data plus derivatives)
• \efit_aeqdsk:vloopt is \mflux:v0 with a 20 ms smoothing window applied (window determined from the IAVEV input parameter to EFIT. I'm not sure if the smoothing is causal.
• If we run EFIT at a 1 ms sampling rate, we could set IAVEV to a value convenient for using smoothed loop voltage measurements output by EFIT. IAVEV does not enter into the equilibrium reconstructions.
• Bob also suggested potentially using Zeff (\spectroscopy:z_ave) as a way to back out the resistivity and calculate Vloop during flattop. I believe Zeff is measured from a band of radiation that's typically devoid of line radiation and therefore dominated by Brehm. This was Earl's diagnostic, so he knows the details. To calculate the resistivity from Zeff, we'd also need to eliminate the Te dependence. I looked at a few shots via the scopes, and Zeff seems pretty noisy, so I don't think this is a path worth taking.

[yumouwei]

Here's a comparison of the raw mflux:v0, smoothed mflux:v0 using either a causal or non-causal (matlab_smooth) boxcar smoothing function over 20 ms window, and vloopt from EFIT18. Looks like vloopt matches neither of the two smoothed signals; it might be that it used a different smoothing function.

Also, what's IAVEV?

[hwietfeldt]

IAVEV is an input to efit located in .NAMELISTS.EFITIN.IAVEV in the efit tree. Its comment in the node for IAVEV is "ms for averaging loop voltage, 20." For both analysis and efit18, IAVEV had a value of 20.