DIII-D EFIT results mismatch between EFIT01 and DIS

[yumouwei]

Description of the problem

• The results of runtag=DIS EFIT tree does not match those of the default EFIT01 tree prior to the high-sampling period of a discharge.
• As of commit e82759cc9123eeaf54a791277303acc916f39319, disruption-py uses EFIT01 for non-disruptive shot and finds the efit tree with runtag=DIS in code_rundb.dbo.plasmas for a disruptive shot. The exact criteria for determining whether a shot is considered disruptive or not is still under investigation.

Sample figures

For the following figures I used a 1ms sampling rate to negate any effect caused by the different time basis between different EFIT trees.

161228 (disruptive shot) Using efit_nickname_setting='disruption' refers to EFIT04 which is the runtag=DIS tree.

166177 (non-disruptive shot) NOTE: in the MATLAB SQL DB, data of this shot were populated using EFIT05 (runtag=DIS) instead of EFIT01 despite being considered as a non-disruptive shot. For this reason running python tests/test_against_cache.py with any EFIT signal will result in failure with data (data mismatch).

Related Issues & PRs

• 237

[gtrevisan]

other questions:

• what is the difference, for both C-MOD and DIII-D, of the EFIT inputs for the vanilla tree (analysis/EFIT01) vs the disruption tree (EFIT18/EFIT##)? is it only about the time base?
• as already established DIII-D shot 166177 is disruptive ("technically, disruption during the rampdown" said Cristina), but it does not have a corresponding disruption time in the disruptions table. why?

actual behavior of EFIT trees changed with:

• 213

[yumouwei]

Also, note that this mismatch between the vanilla tree vs the disruption tree only occurs on DIII-D. I did not notice any difference between analysis and efit18 during the regular discharge period on CMOD.

[yumouwei]

Additional affected signals

• n_e is also obtained from _efit_tree. Force select the runtag=DIS tree also resolves its & dn_dt's mismatches with SQL table.
• greenwald_fraction is computed using n_e, ip and aminor (efit signal). However, aminor has a lot of missing data right before a disruption (see figure below) whereas greenwald_fraction doesn't, which means the MATLAB method for calculating greenwald_fraction must have used some strange extrapolation method to fill in data in those time points.

166177 (non-disruptive shot). MDSplus data retrieved using the efit05 tree instead of efit01 by default of disruption-py. Note the difference of greenwald_fraction prior to the disruption, which is likely caused by the different extrapolation methods used by MATLAB & disruption-py. Update: currently the aminor obtained from disruption-py is computed using the get_shape_parameters() function. This function checks chisq and replaces the values of time slices where chisq > 50 with nan. The greenwald_fraction calculation does perform the check chisq and use all available aminor data to do the calculation, which is why greenwald_fraction has data in the time slices where aminor has nan values.

Forcing get_density_parameters() method to also return aminor (bypass the chisq check)

[gtrevisan]

are you able to recreate your initial plot for 161228 with time 1 s < t < 3 s ? unless I'm mistaken, it would be interesting to see the actual data points (with dot markers) without disruption-py interpolating stuff. can you use timebase = efit and then use, say, linestyle ro for the background line, and linestyle b. for the foreground line?

[yumouwei]

This one is done using the latest dev branch (9f3e485) and time_setting='disruption'. It looks like the errors are intrinsic from EFIT instead of disruption-py doing strange interpolation/extrapolation.

[gtrevisan]

thanks for double checking, what are actually the time steps here for the two efit trees? we'll have to ask the gurus wrt the inputs possibly being different.

[yumouwei]

They are both sampled at every 0.025 s during that time period. By the end of the shot the sampling rate increased to every 0.002 s.