ELM_processing¶
Contacts: David Eldon
Short Description¶
ELM finding and filtering of data based on relationship to ELM timing
Long Description¶
This module supports customizable ELM detection and filtering and is intended to be used as a sub-module in other projects. It works by managing instances of the OMFITelm class. The module itself supplies only GUIs and organizational aids.
Automatically picks which filterscope to use for ELM detection.
ELM detection is accomplished via a difference of smooths type edge detection algorithm, or a new “jump and hold” algorithm. Jump and hold finds the start of an ELM by looking for large increases in input signal in short time windows. It finds the end by holding the ELM flag set until the signal to drops close to pre-ELM levels again. The hold logic for finding the end of an ELM can also be applied as a correction to the classic edge detection algorithm. Edge detection operates on a combined D_alpha measurement and on its time derivative. Different smoothing functions are available.
The module includes a database of manually identified ELMs for comparison, as well as some scripts for comparing automatic to manual detection and building a merit function.
ELM filtering is cast in terms of ELM phase and time since end of last ELM. ELM phase is defined as 0 at the end of an ELM. Phase then increases to 1 immediately before the start of the next ELM, and then jumps to -1 immediately after the start of the ELM. Thus, ELM phase is positive between ELMs and negative during ELMs. An ELM filter can be defined by an acceptable ELM phase range and by thresholds on time since last ELM: first, there is a threshold below which all data are rejected (typically small; <= 1 ms), regardless of ELM phase. This prevents double peaked ELMs from triggering data admittance between the peaks, when ELM phase rapidly ramps from 0 to 1 (assuming these are even detected as two separate ELMs in the first place, which hopefully they won’t be). Next, there is a threshold after which all data are accepted (typically >= 25 ms), regardless of ELM phase. This allows analysis of ELMing and ELM-free time periods without changing settings.
Typical workflows¶
In established modules, ELM_processing will already be interfaced with the necessary scripts. Follow the instructions in the parent module, if any.
- In new modules:
Import ELM_processing as a child of your module
Set up dependencies to point to ELM_processing as needed
Link the GUIs together if desired by using OMFITx.CompoundGUI() to include the elm_detection_GUI, elm_filter_GUI, or elm_plot_GUI
Have an appropriate script call the ELM filter by doing elm_okay = ELM_processing[‘SCRIPTS’][‘ELM_filter’].importCode(times_to_filter=t).elm_okay
Alternatively, you could use the OMFITelm class directly in the scripts of your new module.
Supported devices¶
DIII-D, NSTX, NSTX-U
Contributors¶
List of contributors sorted by number of lines authored:
2940 David Eldon
46 Fusion Bot
14 Nikolas Logan
9 Sterling Smith
4 Will DeShazer
1 Orso Meneghini
Submodules¶
None
Users¶
List of usernames sorted by number of module imports: eldond, xingz, nelsonand, samuellc, thomek, laggnerf, burkem, chabanr, haskeysr, weisbergd, ashourvana, stagnerl, bgrierson, lindan, bykovi, grierson, hongrongjie, logannc, majorm, saarelma, smithsp, victorb, yuguanying, austinm, curtis, david, halfmoonm, holland, jianx, johnsonc, knolkerm, leem, mcclenaghanj, meneghini, mordijck, munarettos, nazikian, orlov, smithdr, wangyingchu, willensdorferm, zamperinis, zegere, zhangt, zhaojin, zywickib