H. Yuh, M. Greenwald, T. Fredian, J. Stillerman, PSFC, MIT W. Dorland, B. Osborn, U. of Maryland

1. Stability Analysis of C-Mod with Gyrokinetic Code GS2 H. Yuh, M. Greenwald, T. Fredian, J. Stillerman, PSFC, MIT W. Dorland, B. Osborn, U. of Maryland M. Kotschenreuther, U. of Texas at Austin

2. MDSplus Data System • MDSplus is a data acquisition and storage structure for experimental data, setup, and analysis. • Used internationally in plasma experiments, including: • Alcator C-Mod at PSFC, MIT • NSTX at PPPL, Princeton • TCV at EPFL, Lausanne • RFX at CNR, Padova • MDSplus uses a hierarchical tree structure containing flexible data type nodes. • A set of X/motif based tools are available to retrieve, display, edit, and analyze data. • MDSplus is based on the client/server model, allowing universal access to centrally stored data. • Remote offsite retrieval of data is transparent • Naturally allows data sharing and collaborations • A common hierarchy facilitates direct cross-site comparison of data • Storage of setup data allows easily reproducible input parameters • All of the above, developed for pulsed experimental data is also desirable for simulation code runs. This work was performed under appointment to the Fusion Energy Sciences Fellowship Program administered by Oak Ridge Institute for Science and Education under the contract number DE-AC05-76OR00033 between the U.S. Dept. of Energy and the Oak Ridge Associated Universities.

3. Motivation to adapt GS2 to MDSplus • Common data structure facilitates experimental data input into simulation codes. • Common access to centralized simulation data • No searching in personal directories for run data • Simulation data naturally ordered by experimental shot number • Cloning of model branch allow rapid deployment of simulation code at additional sites in the future • Access to established experimental visualization tools • All MDSplus tools available • No parsing text files • In cluster computing environments, I/O can be offloaded to third party MDSplus server, reducing node to disk bottlenecks • MDSplus transaction layer is transparent to simulation code • No additional code needed in simulation for these benefits

4. Adaptation of GS2 for C-Mod use • GS2 was developed in f90 and runs on the NERSC Cray T3E • No MDSplus support is available for T3E • T3E security requirements hinders MDSplus server/client development • MDSplus well supported on OpenVMS, an OS widely used at C-Mod but few other locations • Decision was made to port GS2 using MDSplus to Linux platforms, where MDSplus support is available, and growing • Linux MDSplus server and client are functional • Important for site transplanting to other sites where OpenVMS servers are unavailable • GS2 has been ported to Linux previously • Most MDSplus X/motif tools have been ported to Linux. Ongoing development is in progress. • IDL, the preferred analysis environment at C-Mod is available for Linux • Nag95 compiler chosen for code compatibility and support.

5. MDSplus I/O subroutines in Fortran • General purpose f90 MDSplus I/O module was developed. • Compatible with all f90/f95 programs capable of using modules • Overloaded / Compile time resolution MDSplus wrapper • Simple MDS I/O calls from wrapper allows for easy ports to MDSplus for future programs • Example MDS calls: CALL mds_read (“node”, var) CALL mds_read (“node”, var) Where “node” is the MDS node name, and var is of any of the following types: Boolean, Int, Real(Dim 0-7), Double(Dim 0-7), Complex(Dim 0-7), DoubleComplex(Dim 0-7) • Codes (e.g. EFIT, TRANSP) that are hybridized (i.e. using pre/post-processing to handle MDS I/O) can internalize MDS I/O with this wrapper.

6. Java applet interface for GS2 inputs • GS2 MDS tree created • Standard structure among multiples sites running GS2 simulations • It will be possible to submit runs with a web browser • Short implementation time for future sites • A Linux binary distribution of GS2 is a possibility • Java Applet facilitates GS2 input entry • Original program by Bryan Osborn (U. of Md.) • Modified to include MDS entry capabilities • Capable of retrieving GS2 input setups from any MDS server with GS2 tree • Centralized Java client will facilitate code maintenance, updates • It will be possible to submit runs with a web browser

7. GS2 Description • GS2is a (non)linear electromagnetic gyrokinetic stability code • Initial value code, time evolves gyrokinetic equations in time in a flux tube • Uses real local equilibrium conditions, but does not contain global parameters / radial profiles • Does not contain Er

8. Investigating observed C-Mod Quasi-Coherent EDA edge mode with GS2 • Enhanced Ha mode is observed on C-Mod during H-mode produces a continuous effect of reducing particle confinement while maintaining most of the energy confinement. • EDA is not a relaxation process such as ELMs • EDA is seen by the PCI, Reflectometry, and electric/magnetic Langmuir probes • Examples data from PCI showing flow shifted Q-C mode (A. Mazurenko Poster#?) • FFT of PCI data / EDA signal w,k plot of PCI data • Diagnostics show Q-C mode is around 80-150 kHz, with kq ~ 3-6 cm-1 • m ~ 100, n ~ 400 if mode is resonant (q~4 in pedestal)

9. Experimental Te, ne input data profiles: • Shot 1000616013 @ t=1.0s • (Edge Te and ne profiles derived from Thompson scattering data)

10. Experimental geometry input data profiles: • Shot 1000616013 @ t=1.0s • (d and k profiles derived from EFIT)

11. Experimental q, b input data profiles: • Shot 1000616013 @ t=1.0s • (q and b profiles derived from EFIT, Thompson scattering)

12. Radial scan of pedestal • Each run conducted by taking data from 1000616013 @ t=1.0s • Rmid = 88.0 to 89.4 cm in 2mm steps • EFIT calculates Rmid of LCFS at this time to be 90.45cm • Fastest growing modes are in the region of highest b´

13. Rmid, kq scan of C-Mod pedestal • A high resolution kq scan was done for each radial position, near the peak b´ • Mode frequencies, although not flow shifted, are in the range of experimentally observed frequencies • Shaded areas denote experimentally observed range of kq

14. q and b scan at Rmid = 88.8cm and 89.0cm • Selecting the maximum growth rate (kq = 4 and 3 cm-1 respectively) from the 88.8cm and 89.0cm kq scans. A b and q scan was done.

15. Conclusions • GS2 has been ported to Linux and now supports the C-Mod MDSplus data structure • Initial investigations of the observed Quasi-Coherent mode on C-Mod using linear GS2 simulations reveal instabilities at the proper region of w,k space using experimental data from the pedestal region. • Initial parameters scans show these modes are sensitive to changes in gradients in the pedestal • GS2 reports the fastest growing modes at the peak of b´ • Simulation growth rates are the same order of magnitude as predicted by resistive ballooning calculations • The unstable modes from the simulations shows • which is strong enough to account for transport seen in experiments

16. Future Work • Initial investigations of the EDA Q-C mode with linear GS2 runs show potential for further investigation • Nonlinear runs are required to better simulate actual mode properties • Determine transport in simulation and compare with observed transport • Substantial computing power is required for nonlinear runs • Expand sensitivity studies to broader ranges in parameter space • Determine what the EDA mode is (put a name to the mode) • Is it a resistive ballooning? • Predict thresholds for EDA from simulations, and compare with experiment

17. Nonlinear runs at C-Mod • There is active interest in constructing a Beowulf computing cluster at • C-Mod. A GS2 nonlinear port to Linux is nearing complete. • GS2 is parallelized with the MPI library available on Linux • EFIT, TRANSP, and additional simulation codes would also benefit from a local computing cluster • A 24 node cluster connected by fast Ethernet would approximate the computing throughput from 48 T3E nodes (based on Spec95 benchmarks) • T3E has a total of 644 computing nodes (450 MHz Alpha 21164 CPUs) available to users • Cluster would use x86 nodes at ~900 MHz • FFT routine efficiency is an important factor but neglected here • Nonlinear probing runs take approximately 32 - 64 T3E node-hours • 1-1.5 hours on local cluster • Full nonlinear runs take approximately 2048 T3E node-hours • <2 days on local cluster

18. Where’s GS2? • GS2 Runs Here at NERSC • on the T3E • And here, on my desk, on a Linux “box” (no actual box)