Center for Magnetic Reconnection Studies The Magnetic Reconnection Code within the FLASH Framework Timur Linde, Leonid Malyshkin, Robert Rosner, and Andrew Siegel University of Chicago June 5, 2003 Princeton, NJ

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) Overview q FLASH project in general q FLASH role in Magnetic Reconnection Code (MRC) development

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) What is FLASH? What is MRC? q Initially: AMR code for astrophysics problems on ASCI machines (compressible hydro + burning) q FLASH evolved into two things: q More general application code q A framework for building/hosting new problems FLASH physics modules + FLASH framework = FLASH application code Next:  What physics modules does FLASH contain?  What services does FLASH framework contain? Hall MHD modules + FLASH framework = Magnetic Reconnection Code

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) FLASH breakdown q physics modules: (in)compressible hydro, relativistic hydro/MHD, resistive mhd, 2-D Hall mhd, (nuclear) reaction networks, time- dependent ionization, various equations of state, particles, self- gravity, Boltzmann transport, subgrid models, front-tracking q framework: block-structured AMR (Paramesh), parallel io (hdf5), runtime vis (pvtk), runtime performance monitoring (PAPI), generic linear solvers tied to mesh, syntax/tool for building new solvers q code support (public web-based) q flash_test q flash_benchmark q coding standard verification q bug/feature tracker q user support schedule q download:

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) General features of FLASH q Three major releases over four years q 300,000+ lines (F90 / C / Python) q Good performance q Scalable on ASCI machines to 5K procs q Gordon Bell prize (2000) q Emphasis on portability, interoperability q Standardization of AMR output format, data sharing via CCA q Flash 2.3 q New release, scheduled June 1, 2003 q optimized multigrid solver q significant improvements in documentation q ported to Compaq TRU64 q 2-D runtime visualization q optimized uniform grid q support for different mesh geometries q FFT on uniform grid q optimized multigrid on uniform grid q paramesh3.0 q Parallel NetCDF i/o module q Implicit diffusion q Flash 2.4 q Final 2.x version (Sept 2004)

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) FLASH foci q Four initial major emphases q Performance q Testing q Usability q Portability q Later progress in extensibility/reuse: Flash v3.x q Generalized mesh variable database q FLASH component model q FLASH Developer’s Guide

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) The future of Flash q Take this a step further: identify the “actors” A. End-users Run an existing problem B. Module/problem contributors Use database Module interface but unaware of Flash internals C. Flash developers Work on general framework issues, utility modules, performance, portability, etc. according to needs of astrophysics and (laboratory) code validation. q Flash development successively focused on these 3 areas q Flash1.x: emphasis on A q Flash2.x: expand emphasis to B q Flash3.x: expand emphasis to C q Note: q Application scientists lean toward A. and B; programmers/software engineers lean toward C; computer scientists can be involved at any level q Everybody contributes to design process; software architect must make final decisions on how to implement plan.

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) FLASH and CMRS q Follows typical pattern of FLASH collaborations q Prototyping, testing, results initially external to FLASH if desired q Iowa AMR-based Hall MHD – Kai Germaschewski q No “commitment” to FLASH q Interoperability strategy agreed upon q how are solvers packaged? q what data structures are used? q what operations must mesh support? component model

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) CMRS/Flash strategy q Move portable components between FLASH/local framework as needs warrant q People strategy: q FLASH developer leading the FLASH single-fluid MHD work (Timur Linde) leads the Chicago MRC development q CMRS supports a postdoctoral fellow (Leonid Malyshkin) fully engaged in developing/testing the MRC q We also support a new graduate student (Claudio Zanni/U. Torino) working on the MRC and its extensions q Science strategy: q The immediate target of our efforts are on reconnection q Specifically: what is the consequence of relaxing the “steady state” assumption of reconnection - can one have fast reconnection in time- dependent circumstances under conditions in which steady reconnection cannot occur?

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) Using FLASH q Some advantages of FLASH q tested nightly q constantly ported to new platforms q i/o optimized independently q visualization developed independently q documentation manager q user support q bug database q performance measured regularly q AMR (tested/documented independently) q coding standards enforcement scripts q debugged frequently (lint, forcheck) q sophisticated versioning, repository management q possible interplay with other physics modules (particles, etc.)

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) Where are we now? q We have a working 3-D resistive/viscous AMR MHD code q Has already been used by R. Fitzpatrick in his study of compressible reconnection q MRC v1.0 exists q FLASH and 2-D Hall MHD have been joined and are being tested q Required elliptic solves for Helmholtz, Poisson (i.e., multigrid) q Based on reusable components q This was done by importing the Iowa Hall MHD code as a “module”, but using our own Poisson and Helmholtz solvers; hence we solve exactly the same equations as the Iowa “local framework” q We are now running comparisons of MRC with the Iowa Hall MHD code q The next steps are q Inclusion of full 3-D Hall MHD, again implemented in a staged manner (almost completed) q More flexible geometry: cylindrical, toroidal

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) Concluding remarks q Code emphases: q Standards of interoperability q Simple: common i/o formats – can reuse postprocessing tools q More complex: reusing solvers from one meshing package in another – libAMR (Colella) q More complex: standard interface for meshing package q Robustness, performance, portability, ease of use q Science emphases: q Focus is on an astrophysically-interesting and central problem q Problem is also highly susceptible to laboratory verification

Center for Magnetic Reconnection Studies (Univ. of Chicago branch) Questions and discussion … which brings us to