Contacts: Phil Snyder, Orso Meneghini, Samuli Saarelma, Jin Myung Park

Short Description

Executes the EPED pedestal-stability code and its neural-network counterpart EPED1-NN


Pedestal, MHD, stability, boundary condition, edge

Long Description

EPED is a model to predict the height (ie pressure, or temperature at a given density) and width of the H-Mode pedestal in tokamaks. EPED requires a set of few (8) scalar inputs: a betan bt delta ip kappa neped r zeffped It predicts a boundary condition (near the top of the pedestal, typical psi_norm~0.9-0.95) that can be coupled to a core transport solver such as TGYRO to predict profiles across the confined plasma. EPED has been tested on more than 300 cases on 5 tokamaks (DIII-D, JET, C-Mod, AUG and JT-60U), typically finding agreement with observations to a standard deviation of ~20%.

EPED first calculates a kinetic ballooning mode constraint using series of model equilibria from TOQ and stability calculations from baloo (or in the future, GYRO or TGLF), and then calculates a peeling-ballooning mode stability constraint using model equilibria from toq and stability calculations with ELITE. The two constraints are combined to determine the two unknowns, pedestal height and width.

EPED is designed to predict the pedestal structure in “high performance” H-mode operation (ie Type I ELM or QH-Mode regime), and typically provides an upper bound in other modes of operation. Note that EPED assumes the discharge is in “high performance” H-mode operation and does not predict the conditions for access to this regime.

EPED is applicable to “standard” aspect ratio tokamaks (DIII-D, JET, ITER, FNSF, JT-60SA etc) and requires further work to be applicable to low aspect ratio devices such as MAST or NSTX. EPED can be applied to predict and optimize future devices such as FNSF, ARIES, JT-60SA, and CFETR, and has been extensively used by the ITPA ISM group and the ITER group itself for ITER performance predictions.

The global Shafranov shift (ie global beta poloidal) impacts pedestal stability, and hence is an input to EPED. This couples the pedestal predictions from EPED to core profile predictions (eg from TGYRO), and hence one must iterate the coupled core-EPED system to reach a self-consistent solution for both pedestal and core profiles given a set of sources. EPED predicts the pedestal structure as a function of density, and hence can be used to optimize the density for best fusion performance, but EPED does not by itself predict the density.

A typical EPED run requires construction of ~300 model equilibria, and ~2000 baloo and ~1000 ELITE calculations, but most of this is embarrassingly parallel. The IPS framework is used to manage the parallel execution of the EPED workflow: the equiliibria are first constructed in parallel, then all the BALOO runs in parallel, then all the ELITE runs in parallel.


Running EPED requires having a NERSC account! To request one go to https://iris.nersc.gov/add-user and use AToM for the repository name.

Typical workflows

This module is used to:

  • Execution as IPS workflow, on HPC system (leveraging the IPScore module)

  • Execute parametric scans using the IPS DAKOTA capabilities
    • Generation of uniform scans, scans based on DIII-D AOT, random sampling

    • Restart scan capability

    • Avoid running data points already in the database

  • Setup of input files based on metrics of a gEQDSK file and profiles from ONETWO statefile

  • Postprocessing to identify condition, with rejection of failed runs

  • Generate Osborne p-file from EPED (TOQ) profiles

  • Use EPEDNN neural network based model to perdict EPED1 results
    • Interactively perform sensitvity scans and profiles variations based on EPEDNN

    • Compare EPEDNN predictions with autoONETWO data for DIII-D shots

Supported devices

  • Device independent

  • Comparison with DIII-D experimental data


List of contributors sorted by number of lines authored:

2333 Orso Meneghini
 339 Fusion Bot
 200 Joseph McClenaghan
  82 Tim Slendebroek
  73 Brendan Lyons
  34 Samuli Saarelma
   2 Sterling Smith
   1 Will DeShazer


List of usernames sorted by number of module imports: meneghini, zhuyiren, kongd, mcclenaghanj, knolkerm, nelsonand, wanghuiqian, lyonsbc, howardnt, lig, xiangjian, ashourvana, orlov, jwhughes, huqiming, guowf, wangy, likai, zhouchengxi, holland, xuemiao, chenxi, grierson, lanctot, nazikian, jlchen, polifm, chenji, saarelma, smithsp, wilkstm, bortolon, snyder, lijx, luoyiming, osborne, wmq, jianx, zhaodeng, bgrierson, kripner, marinoni, solomon, stephanet, xugl, zegere, aashourv, capitainetema, cxzhou, evans, inyong, johnsonc, slendebroekt, xuelei, blyons, chenj, dingsiye, eldond, fernandezp, haskeysr, jurban, laggnerf, lizeyu, lwsheng, paz-soldan, renq, sunap, urban, xug, xugs, zhanghongming, zywickib, banerjees, baradakk, duttas, kinsey, kyungjin, lfluo, nanshi, orozcod, pankin, victorb, wangzw, weisbergd, wumuq, zhaixm, zhaojin, zhuzj