In order to self-consistently investigate kinetic effects of runaway electrons under non-axisymmetric magnetic perturbations in tokamaks, the Fokker-Planck code CQL3D has been modified and interfaced with the 3D extended MHD code NIMROD. NIMROD computes radial profiles of plasma density, temperatures, electric field and magnetic perturbation. CQL3D reads these profiles and computes runaway electron populations and their current density at different radial locations. This information is then passed back to NIMROD to further evolve the plasma density, temperatures, electric field and magnetic perturbation. In the previous version of CQL3D, the magnetic field perturbation is taken to be an input and uniform across radial surfaces. In the revised version, CQL3D reads the radial profile of the magnetic perturbation computed by NIMROD directly and computes the radial population of runaway electrons over the entire plasma radius. For benchmarking, current and density fractions of runaway electrons computed from the revised version and the previous version are compared without iterations with NIMROD using experimental conditions from a previous DIII-D runaway electron experiment [R.W. Harvey, V.S. Chan, S.C. Chiu, T.E. Evans, M.N. Rosenbluth, Phys. Plasmas 7, 4590 (2000)]. Results from the two versions are in good agreement. Further simulations and comparisons against DIII-D runway electron experiments are planned.

Both the fusion and DIII-D websites were successfully migrated to newer, more robust web servers. The old web server systems were outdated and have been retired. In addition to the hardware upgrade, website security enhancements and software updates were also applied during the migration. As planned, the server migration improved website reliability and performance, which resulted in an enhanced user experience. We plan to update the various website software and apply security patches annually. Security patches may be applied more frequently if needed.

The OpenMP (OMP) implementation in GYRO has been re-engineered by Bob Walkup from IBM. The basic strategy has been to keep the number of parallel and work-sharing regions to a minimum, adding “!$omp barrier” directives where needed to synchronize all OMP threads. Also, inner loops have been block partitioned. To accomplish this, the block-partitioned loop indices are computed once only and stored in a module with the “threadprivate” data attribute. Some additional MPI-related improvements were accomplished by packing larger data objects into the repeated calls to MPI_ALLTOALL. On the IBM BlueGene/Q machine, the performance with 16 OMP threads is doubled in comparison to the original OpenMP implementation. What is particularly remarkable is that now, even for the standard test case using 128 MPI tasks, cases with super-linear scaling are found: 2.5X speedup on 2 OpenMP threads, and 4.3X speedup with 4 OpenMP threads.