On the OMFIT modeling framework and the development of steady ...

On the OMFIT modeling framework and the 

development of steady state scenarios for a 

Fusion Nuclear Science Facility 

November 14 - 16, 2012 University of Kyoto, Kyoto, Japan 

Orso Meneghini 

S. Smith ⋆ , H. St John ⋆ , A. Garofalo ⋆ , L. Lao ⋆ , V. Chan ⋆ 

Oak Ridge Associated Universities 

⋆ General Atomics 

November 16 th 2012

Integrated modeling in magnetic fusion 

Integrated modeling: self-consistent interaction of specialized codes 

to capture complex interplay of different physical processes 

Manual integration of different codes is a complicated endeavor 

Many integrated modeling softwares have been developed 

(SWIM, ONETWO, CRONOS, TRANSP, CORSICA, ITM-IT, TASK, ...) 

Two main categories: 

1 Transport solver: 

• External components to calculate equilibrium, sources and fluxes 

• Tight coupling: Data exchange at memory level 

2 Workflow-manager: 

• Data “flows” through the components 

• Loose coupling: Data exchange through files

Conventional IM frameworks define data structures, codes 

integration and usage for the users 

TOP-DOWN approach 

1 Overall vision guides creation of framework and its components 

e.g.: 

• Simulating plasma discharge start to finish 

• Couple edge and core transport 

• Improve physics model by high performance computing 

2 Standard data structures to allow data exchange 

• Statefile(s), CPO, PBSD, ITER?, ... 

Standard data structures are in principle an effective idea, however 

they comes with additional complexity and cost: 

• Many subtleties need to be figured out 

• Agreement with all parties 

• Hard to convince developers to alter their codes 

There is a disconnect between this TOP-DOWN approach and 

every-day specific needs of many theorists and experimentalist

One Modeling Framework for Integrated Tasks (OMFIT) 

is a workflow-manager developed to bridge this gap 

Change of paradigm: BOTTOM-UP approach 

1 Framework provides the tools while interaction is defined by users 

• Allow users to define the codes coupling 

• Components grow in an organic fashion, based on the specific 

problem of its users 

Same difference of enciclopedia Vs. wikipedia 

OMFIT is a “wik-integrated-modeling” framework 

2 Allow integration without need of standard data structures

One Modeling Framework for Integrated Tasks (OMFIT) 

is a workflow-manager developed to bridge this gap 

Change of paradigm: BOTTOM-UP approach 

1 Framework provides the tools while interaction is defined by users 

• Allow users to define the codes coupling 

• Components grow in an organic fashion, based on the specific 

problem of its users 

Same difference of enciclopedia Vs. wikipedia 

OMFIT is a “wik-integrated-modeling” framework 

2 Allow integration without need of standard data structures 

GREAT ATTEMPT 

INTEGRATED MODELING 

FESTIVAL 2012 

“IT SIMPLY FILLS YOU WITH JOY” 

“AN ABSOLUTE MUST SEE” 

“IT WILL HAVE YOU HOULING !”

OMFIT philosophy and design 

• Recognize and encourage reuse of existing work 

• Allow inter-operativity of many data formats 

• Easily integrate existing scripts/widgets/softwares/... 

• Ease the way of working... 

• Interactive graphical environment 

• High level APIs for remote& parallel execution, GUIs, visualization 

• GUIs hide complexity for streamline analysis & inexperienced users 

• ...without limiting possibilities 

• All data/parameters are always accessible 

• Modular structure with arbitrary organization 

• Scripting (Python) 

• Facilitate modeling-experiment interaction 

• Integration with MDS+, PTDATA, SQL databases, etc... 

• Create a cooperative environment 

• Sharing of physics modules among users 

• Open-source, based on open-source software 

• It’s all about being generic, generic and generic

1 The OMFIT framework 

The OMFIT tree structure 

OMFIT interactive graphical environment 

Additional features: user GUIs, high level APIs, MDS+ integration, 

visualization 

2 Achievements and physics results 

Control-room analysis of gyro-kinetic stability 

MHD stability survey 

Magnetic flutter model for RMP-induced transport 

NTV model for NRMF-induced rotation 

Scenario development for DIII-D AT discharges 

3 Development of steady-state scenarios for FDF 

Improved LHCD system of FDF 

Integrated modeling in OMFIT with Eφ = 0 and β constraints 

Preliminary results using GCNMP/GLF23 transport model 

4 Conclusions and future developments

Main idea: to treat files, scripts, experiment data, texts, 

plots, executables, ... as a uniform collection of objects 

• Centralize data from different sources, independent of origin 

• Store everything deemed relevant, with no a-priori decision of 

which variables are stored and how 

• Support of few data formats allows interaction with many codes 

(Does not preclude use of statefiles, etc...) 

MDS+ 

NetCDF 

Python 

FORTRAN namelist 

OMFIT 

Non standard 

IDLsave 

MATLAB 

Unied 

data access 

Unied 

data structure 

Unied intertask 

communication 

Unied 

GUI, API and 

visualization

Data is organized in a a single, self-descriptive, hierarchical 

structure structure (OMFIT tree), which provides unified data 

access and sets objects in a context 

ONETWO 

(modules) 

Gfile 

(EFIT file) 

… 

FILES 

(directory) 

CASE (str) 


RMAXIS (float) 

NW (int) 

PSIRZ (array) 

Kfile 

(namelist) 

EFIT 

(module) 

SCRIPTS 

(directory) 

runEFIT 

(python) 

GUIS 

(directory) 

PLOTS 

(directory) 

SETTINGS 

(namelist) 

• Objects are further organized into modules: collections 

of objects used to solve elementary physics problem 

• Data containers (e.g. files) are interpreted and their 

data populates the tree 

• Objects can be directly accessed/manipulated in a 

unified way, independently of their type or origin 

e.g. OMFIT[EFIT’][FILES’][Gfile’][PSIRZ]

Unified data structure inherently defines a memory space 

where inter-tasks communication can dynamically occur 

ONETWO 

(modules) 

Gfile 

(EFIT file) 

… 

FILES 

(directory) 

CASE (str) 


RMAXIS (float) 

NW (int) 

PSIRZ (array) 

Kfile 

(namelist) 

EFIT 

(module) 

SCRIPTS 

(directory) 

runEFIT 

(python) 

myExample 

(python) 

GUIS 

(directory) 

PLOTS 

(directory) 

SETTINGS 

(namelist) 

OMFIT[’ONETWO']['SCRIPTS'][’ONETWOexec'].run() 

for scale in [0.9,1.0,1.1]: 

OMFIT[‘EFIT’]['FILES'][‘Kfile']['IN1']['PRESSR']=\ 

OMFIT[’ONETWO’]['FILES']['statefile']['press’]*scale 

OMFIT['EFIT'][’SCRIPTS']['EFITexec'].run() 

print(OMFIT[‘EFIT’]['FILES'][‘Gfile’][‘RMAXIS’])

OMFIT data structure allows unified top-level GUI to manage 

tree objects, run simulations and analyze data interactively 

Tree browser 

Objects 

description 

Search 

Status bar 

Console 

Command box

High level Python APIs allow users to: 

Execute tasks remotely and in parallel 

• Remote code execution and file upload / download via SSH 

• Parallel execution of the same task with different input 

parameters, on multiple remote machines 

• Real-time monitoring of local / remote and serial / parallel tasks 

• Run codes where they already work! 

→ No need to compile all codes on one system 

Host 

Server on 

same network 

ssh 

Firewall or 

login node 

Internet 

Servers 

directly 

reachable 

Servers 

behind 

firewall 

Monitor progress of parallel execution 

Running process Completed process

High level Python APIs allow users to: 

Quickly create Graphical Users Interfaces (GUIs) 

User GUIs speed-up routine analysis 

and hide any of the underlying 

complexity to inexperienced users 

• GUIs are python scripts and can 

be created/ modified by users 

themselves 

• Easy! For each GUI entry need to 

specify: 

• A label 

• Associated OMFIT tree variable 

• GUIs can be nested to create 

arbitrarily large GUIs, while 

ensuring consistency 

ONETWO 

KineticEFIT 

EFIT 

PROFILES

Visualization of experimental and modeling data allows 

quick inspection and analysis 

Kinetic EFIT iterations 

M3D-C1 simulation of 

RMP pressure perturbation 

• 1D/2D arrays can be 

quickly inspected with the 

push of a button 

• Plots are objects which 

can be stored in the 

OMFIT tree 

• Plots are interactive and 

can be customized (à la 

MATLAB, though still with 

some limitations) 

• Over-plot results from 

different analyses / codes 

/ iterations / ... 

• More exotic plots can be 

scripted in Python 

• Plots scripts can be 

assigned to specific 

objects

MDS+ tree, PTDATA signals, SQL tables are also integrated 

into the OMFIT tree 

• Experimental data can be directly accessed and visualized 

• e.g. Create input for codes or compare models with experiments 

MDS+ traverser

Python scripting empowers users with limitless capabilities 

and available libraires simplify users job 

Example: Easy to setup non-linear parameter optimization based on 

cost function approach: 

• Change SCALEPP EXT variable in EFIT to obtain βp = 0.4 

def cost_f(x): 

OMFIT['EFIT']['FILES']['rfile']['PROFILE_EXT’]['SCALEPP_EXT']=x[0] 

OMFIT['EFIT']['SCRIPTS']['EFITexec'].run() 

cost=(OMFIT['EFIT']['FILES']['aEQDSK']['betap']/0.4 - 1)**2 

return cost 

x=[1.0] 

res = scipy.optimize.fmin(cost_f, x) 

Cost function Vs SCALEPP_EXT per iteration 

2 

4 

6 

5 

7 

8 

3 

1

Growing list of available modules 

Equilibrium 

• EFIT 

• KineticEFIT 

Transport 

• ONETWO 

• GCNMP 

• FASTRAN 

Profiles 

• GAprofiles 

• ZIPFIT 

Gyro-kinetic 

• TGLF 

• GKS 


MHD stability 

• PEST3 

• GATO 

Others 

• GENRAY 

• M3DC1 

• NTV 

• Magnetic 

flutter 

• Integrating codes into 

OMFIT automatically 

endows them with new 

capabilities 

• Easy to support new codes, 

especially if they use 

standard file formats like 

namelists or NetCDF 

• Need the know how of an 

expert to setup a modules. 

Users exploits this know how, 

especially with available 

users GUIs. 

• Modules are shared among 

users (now via GitHub), 

tools to compare/merge 

import/export





visualization 












OMFIT used for control-room MSE+kinetic constrained EFITs 

and analysis of gyro-kinetic stability 

Experiments aimed at probing critical gradient and stiffness of the 

electron temperature profile by localized electron cyclotron heating 

• Integration with DIII-D profile fitting tools, ECH and NBI from 

experiments (via existing IDL routines) 

• OMFIT provided quick feedback to guide experiments TGLF 

simulations to identify modes structures as a function of 

wavenumber and radii 

ETG 

40 TGLF local linear stability simulations, run 10 at the time in parallel S. Smith APS 2012 

ITG

Survey of linear MHD stability at increased βn 

Pressure scanned 

by scaling of P ′ and 

evaluated MHD 

stability for different 

toroidal mode 

numbers n and wall 

distances 

(conformal) 

220 GATO simulations run 20 at the time in parallel on 3 machines 

N =3.4 N =3.9 N =4.4 N=4.9 N=5.4

OMFIT as the framework for testing magnetic flutter model 

for RMP-induced transport 

Magnetic flutter model reproduces fairly 

well Te at top of pedestal 

Workflow: 

• M3D-C1 calculates spectrum of 

perturbations 

• Experimentally measured “I” and “C” 

coil currents, linearly combine 

perturbations 

• Magnetic flutter model implemented 

in OMFIT predicts χe based on δB 

• ONETWO transport code calculates 

pedestal Te 

P. Raum APS 2012; S. Smith ITPA 2012

OMFIT as the framework for testing NTV model for 

NRMF-induced rotation 

Calculated torque from new framework is 

consistent with measured NRMF torque 

Similar workflow to magnetic flutter study 

A.J. McCubbin APS 2012

Validation of the NTV model with the DIII-D experiment 

NTV calculated on a grid of C-coil n=1 amplitude and phases 

• Linear combinations of intrinsic error and C-coil field 

• 121 points, yet < 10 min thanks to parallelization 

• NTV model predicts peak torque which is not necessarily 

coincident with empirical experimental observation 


M3D-C1 

C coil 

ZIPFIT 

ONETWO 

Kinetic 

EFIT 

EFIT 

M3D-C1 

Error elds 

Linear 

Combinations 

Parallelized 

Flux-surface 

Average 

NTV 

Calculations 

NTV 

Contour Map 

Integrated NTV torque relative to empirical optimum 

NTV 

optimum 

Empirical 

optimum 

C. Paz-Soldan

Workflow to optimize DIII-D AT discharge 

(e.g. maximize βn) was implemented in OMFIT 

xneo 

EXB 

EFIT 

Magnetics + MSE 

Prole tting 

ZIPFITproles 

Script-based proles tting 

GAproles 

Interactive proles tting 

EFIT 

Scale kinetic P constraint 

257x257 , ε=1E-6 

Evaluate maximum achievable βn 

Kinetic constraint of EFIT equilibrium 

ONETWO 

Analysis mode 

(NFREYA, TORAY) 

EFIT 

Magnetics + MSE + Kinetic 

GATO 

Evaluate MHD stability 

realistic wall, n





visualization 












Previous work found self-consistent steady-state Q=3 

scenario for FDF tokamak 

Solution found by taking 

advantage of disparate 

transport and current 

diffusion timescales 

Baseline EC+LH scenario 

has desirable AT features 

Poor LHCD performance 

lead to considering ECH 

only solution 

A. Garofalo, APS 2012 

FDF Modeling Yields Full Non-Inductive Current Drive 

and High Fusion Power with Combination of EC and LH 

No NBI 

1.5-D 

OneTwo+GLF23+EFIT 

simulation 

Most 

challenging 

scenario, but 

ECH/ECCD 

only 

ECH/ECCD 

+ LHCD 

• Simplifies Tritium 

containment 

• Increases area for Tritium 

breeding 

• Negative-ion NBI technology 

uncertain 

Too much ECCD power 

required for steady-state 

baseline scenario (β N ~3.7) 

Steady-state baseline equilibrium: 

Q~3, Pfus ~230 MW, 

PEC =55 MW, PLH =25 MW, 

H98y2 ~1.2, ƒBS ~70% 

Steady-State Equilibrium for Baseline FDF 

Mode Has Desirable AT Features 

V. Chan, APS 2011

OMFIT used to find new solution based on 

improved LHCD system 

Existing LHCD system suffers of wave 

accessibility problems 

Waves are trapped at the plasma edge 

between the slow and fast cutoff layers 

• Due to high density and steep density 

gradient (H mode) 

• Poor control of the location of the power 

deposition profile (chaotic solution?) 

OMFIT was used to asses possible solution: 

1 Increase n 

2 Change launching location 

Z 

2.0 

1.5 

1.0 

0.5 

0.0 

0.5 

1.0 

and find a new steady state equilibrium 1.5 

Ray trajectories

Solution 1: Increase n makes waves accessible and 

reduce the amount of refraction 

Ray trajectories 

Problems: 

• Low current drive efficiency 

∝ 1/n • Power deposited at 

the very edge 

 

Te(keV ) ≥ 50/n 2 

Z 

2.0 

1.5 

1.0 

0.5 

0.0 

• Lower power handling 

• Coupling is more difficult (high n waves are 0.5 

more evanescent below cutoff density) 

1.0 

1.5

Solution 2: Inner wall launching location is promising 

but may be an engineering challenge Ray trajectories 

• n tends to upshift 

→ Higher n at higher ne 

• Density gradients are less steep 

→ Less refraction 

• Higher B 

→ Less stringent accessibility criterion 

• No trapped electrons 

→ Higher η CD 

• Robust single-pass absorption 

• Less power lost in the SOL 

• Reliable control of LHCD profile 

How to launch these waves? 

Z 

2.0 

1.5 

1.0 

0.5 

0.0 

0.5 

1.0 

1.5

Solution 2: Poloidal-splitter antenna to launch LH waves 

from the high field side 

Same antenna type used in Alcator C-Mod (low field side), and 

proposed for the Vulcan Tokamak (high field side) 

• Quiescent plasma is good for coupling 

• Central stack as toroidally Y.A. Podpaly continuous et al. / Fusion limiter Engineering and Design 87 (2012) 215– 223 

Y. Podpaly, FED 2012 

g. 12. Vulcan LHCD concept illustration, with LH waveguide and launcher shown 

Plasma 

Dierential phase 

Output waveguides 

Common phase 

A 

D 

B 

C 

Fig. 13. Estimated Phase shifter power losses in avera 

klystron to plasma.

Solution 2: Sensitivity study to inner wall poloidal launch 

location and launched n 

150 GENRAY simulations run overnight in OMFIT to search for: 

• Highest current drive efficiency 

• Deepest wave penetration 

“Reliable optimum” found over a broad region in parameter space

Optimized inner wall launch shows superior characteristics 

compared to outer wall launch

Optimized inner wall launch shows superior characteristics 

compared to outer wall launch

Previously: Eφ = 0 and β = βtarget imposed by 

adjusting LH and ECH powers by trial and error 

Separation of transport and current evolution timescales 

OneTwo/GLF23 

~1 sec. evolution 

j, T e , T i , 

Vary heating to 

match target beta 

Free-boundary 

EFIT 

Core 

density 

profile 

shape 

similar to pressure profile 

Free-boundary 

EFIT 

OneTwo/GLF23 

E / r = 0 

j 

Vary current drive 

to obtain Ef =0 

User-intensive process: painful, lengthy and prone to mistakes

OMFIT driven simulation with simultaneous constraint of 

Eφ = 0 and β = βtarget imposed by Newton method 

ONETWO/GCNMP 

Evolve Te,Ti 

~1 sec, xed sources 

Find δβn/δPECH and change 

ECH power to obtain target βn 

PECH + δPECH 

ONETWO/GCNMP 

Evolve Te,Ti 


PECH 

ONETWO/GCNMP 

Evolve Te,Ti 


TORAY 

GENRAY 

statele.txt 

ONETWO 

Make self-consistent 

statele for GCNMP 

statele.nc inone 

eqdsk 

TORAY 

GENRAY 

EFIT 

Find equilibrium 

satisfying force balance 

inone statele.nc 

PLH 

ONETWO 

Evolve J 

δEφ/δρ = 0 

PLH + δPLH 

ONETWO 

Evolve J 


Find δEφ/δPLH and change 

LH power to obtain Eφ = 0 

ONETWO 

Evolve J 


eqdsk*

1st step of current evolution 

Eφ = 0 condition is well imposed with 20 MW of LH power 

Initial 

current evolution step 1

After 1s of GCNMP/GLF23 Te Ti evolution 

profiles develop fine structures and steep gradients 

0.1 s 

... 

1.0 s 

-6 

t=10 s 

• Strongly affects boostrap current → current drive & equilibrium 

• Not observed in original ONETWO/GLF23 simulations 

• Need to understand why, it’s ongoing work





visualization 












Conclusions and future developments 

Newly developed OMFIT framework is a workflow manager which 

based on a bottom-up approach 

• Framework provides the tools while interaction is defined by users 

• Allow integration without the definition of standards 

→ tree structure 

OMFIT is being used for a wide range of tasks: 

• Kinetic EFITs & control room analysis: support for experimentalist 

• Validation of NTV/magnetic flutter theories 

• Preliminary scenario development for DIII-D and FDF 

Future work: 

• Add more data-types and modules based on needs 

• Transition from ONETWO to GCNMP with sources calculated 

within OMFIT 

• Tutorials, online help, support 

• Work closely with experimental DIII-D groups

On the OMFIT modeling framework and the development of steady ...

Create successful ePaper yourself

Delete template?

Save as template?