search

MIT-PSFC / disruption-py

An open-source physics-based Scientific Framework for Disruption Analysis of Fusion Plasmas for AI/ML applications
https://mit-psfc.github.io/disruption-py/
MIT License
9 stars 0 forks source link

Inconsistent Flattop Calculations #266

Open amdecker opened 2 months ago

amdecker commented 2 months ago

Matlab

Both flattop calculations are the same in each machine's get_flattop_indices.m script

https://github.com/MIT-PSFC/disruption-py/blob/5a13906aba52b22fc4119e7f867443d7936f3d03/CMOD/matlab-core/get_flattop_indices.m#L9-L11

https://github.com/MIT-PSFC/disruption-py/blob/5a13906aba52b22fc4119e7f867443d7936f3d03/DIII-D/get_flattop_indices.m#L9-L11

But in the define_indices.m scripts for each machine they are defined differently from each other and from the get_flattop_indices.m script.

https://github.com/MIT-PSFC/disruption-py/blob/5a13906aba52b22fc4119e7f867443d7936f3d03/CMOD/matlab-utils/define_indices.m#L16

https://github.com/MIT-PSFC/disruption-py/blob/5a13906aba52b22fc4119e7f867443d7936f3d03/DIII-D/utils/define_indices.m#L32-L36

And the plot_Ip_error.md script has another calculation: https://github.com/MIT-PSFC/disruption-py/blob/5a13906aba52b22fc4119e7f867443d7936f3d03/CMOD/matlab-utils/visualization_code/plot_Ip_error.m#L25-L27

And this script for EAST defines the rampup as starting at 0.2 rather than the start or based on the programmed Ip time deriv https://github.com/MIT-PSFC/disruption-py/blob/5a13906aba52b22fc4119e7f867443d7936f3d03/EAST/disruption_warning_database.m#L138-L142

DisruptionPy

Our DisruptionPy calculations for the two machines are also different.

C-Mod flattop calculation: https://github.com/MIT-PSFC/disruption-py/blob/6a1c64f25975bb76c627b5a1199691c157ebde2e/disruption_py/settings/domain_setting.py#L111-L113

DIII-D flattop calculation: https://github.com/MIT-PSFC/disruption-py/blob/6a1c64f25975bb76c627b5a1199691c157ebde2e/disruption_py/settings/domain_setting.py#L174-L178

We define the rampup for C-Mod as everything up to the flattop (though this flattop calculation is different from the previous flattop calculations): https://github.com/MIT-PSFC/disruption-py/blob/6a1c64f25975bb76c627b5a1199691c157ebde2e/disruption_py/settings/domain_setting.py#L202-L204

There is no method _get_domain_d3d in RampupAndFlattopDomainSetting.

Questions

  1. Which of these definitions for the flattop do we want to use in DisruptionPy and why?
    • Document the decision making/reasoning given there are so many alternative calculations
  2. How should we define the rampup and rampdown? Can the rampup and rampdown always be defined in relation to the flattop where the rampup is everything before the start of the flattop and the rampdown is everything after the flattop?
  3. Does anyone use these domain settings in DisruptionPy?
amdecker commented 2 months ago

On the subject of domain settings, here's another suggestion:

Make a new method 

get_flattop(ipprog, dipprog_dt):
    indices_flattop_1 = np.where(np.abs(dipprog_dt) <= 1e3)[0]
    indices_flattop_2 = np.where(np.abs(ipprog) > 1.0e5)[0]
    ...

to take the calculation of the flattop indices out of domain_setting.py and into the machine folder, either in the proper physics.py if we are treating cmod and d3d flattops differently, or into a new file shared between the tokamaks.

This would avoid circular imports that arise when we need the flattop inside a physics method -- right now domain_setting.py needs to import physics.py to get CmodPhysicsMethods._get_ip_parameters, and if we need the flattop calculation in physics.py it would lead to a circular import.

@hwietfeldt runs into that issue with _get_te_profile_params_ece here: https://github.com/MIT-PSFC/disruption-py/blob/0183537573d537702eb24ff3f727665ac5638f3b/disruption_py/machine/cmod/physics.py#L1227