The Magnetic Reconnection Code within the FLASH Framework

1
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

2
Overview

• FLASH project in general
• FLASH role in Magnetic Reconnection Code (MRC)
  development

3
What is FLASH? What is MRC?

• Initially AMR code for astrophysics problems on
  ASCI machines (compressible hydro burning)
• FLASH evolved into two things
• More general application code
• A framework for building/hosting new problems

FLASH physics modules FLASH framework
FLASH application code
Hall MHD modules FLASH framework
Magnetic Reconnection Code

• Next
• What physics modules does FLASH contain?
• What services does FLASH framework contain?

4
FLASH breakdown

• 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
• 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
• code support (public web-based)
• flash_test
• flash_benchmark
• coding standard verification
• bug/feature tracker
• user support schedule
• download http//flash.uchicago.edu

5
General features of FLASH

• Three major releases over four years
• 300,000 lines (F90 / C / Python)
• Good performance
• Scalable on ASCI machines to 5K procs
• Gordon Bell prize (2000)
• Emphasis on portability, interoperability
• Standardization of AMR output format, data
  sharing via CCA
• Flash 2.3
• New release, scheduled June 1, 2003
• optimized multigrid solver
• significant improvements in documentation
• ported to Compaq TRU64
• 2-D runtime visualization
• optimized uniform grid
• support for different mesh geometries
• FFT on uniform grid
• optimized multigrid on uniform grid
• paramesh3.0
• Parallel NetCDF i/o module

6
FLASH foci

• Four initial major emphases
• Performance
• Testing
• Usability
• Portability
• Later progress in extensibility/reuse Flash v3.x
• Generalized mesh variable database
• FLASH component model
• FLASH Developers Guide

7
The future of Flash

• 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.
• Flash development successively focused on these 3
  areas
• Flash1.x emphasis on A
• Flash2.x expand emphasis to B
• Flash3.x expand emphasis to C
• Note
• Application scientists lean toward A. and B
  programmers/software engineers lean toward C
  computer scientists can be involved at any level
• Everybody contributes to design process software
  architect must make final decisions on how to
  implement plan.

8
FLASH and CMRS

• Follows typical pattern of FLASH collaborations
• Prototyping, testing, results initially external
  to FLASH if desired
• Iowa AMR-based Hall MHD Kai Germaschewski
• No commitment to FLASH
• Interoperability strategy agreed upon
• how are solvers packaged?
• what data structures are used?
• what operations must mesh support?

component model
9
CMRS/Flash strategy

• Move portable components between FLASH/local
  framework as needs warrant
• People strategy
• FLASH developer leading the FLASH single-fluid
  MHD work (Timur Linde) leads the Chicago MRC
  development
• CMRS supports a postdoctoral fellow (Leonid
  Malyshkin) fully engaged in developing/testing
  the MRC
• We also support a new graduate student (Claudio
  Zanni/U. Torino) working on the MRC and its
  extensions
• Science strategy
• The immediate target of our efforts are on
  reconnection
• 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?

10
Using FLASH

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

11
Where are we now?

• We have a working 3-D resistive/viscous AMR MHD
  code
• Has already been used by R. Fitzpatrick in his
  study of compressible reconnection
• MRC v1.0 exists
• FLASH and 2-D Hall MHD have been joined and are
  being tested
• Required elliptic solves for Helmholtz, Poisson
  (i.e., multigrid)
• Based on reusable components
• 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
• We are now running comparisons of MRC with the
  Iowa Hall MHD code
• The next steps are
• Inclusion of full 3-D Hall MHD, again implemented
  in a staged manner (almost completed)
• More flexible geometry cylindrical, toroidal

12
Concluding remarks

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

13
which brings us to
Questions and discussion