FLASH is a publicly available high performance application code which has evolved into a modular, extensible software system from a collection of unconnected legacy codes. FLASH has been successful because its capabilities have been driven by the needs of scientific applications, without compromising maintainability, performance, and usability. In its newest incarnation, FLASH3 consists of inter-operable modules that can be combined to generate different applications. The FLASH architecture allows arbitrarily many alternative implementations of its components to co-exist and interchange with each other, resulting in greater flexibility. Further, a simple and elegant mechanism exists for customization of code functionality without the need to modify the core implementation of the source. A built-in unit test framework providing verifiability, combined with a rigorous software maintenance process, allow the code to operate simultaneously in the dual mode of production and development. In this paper we describe the FLASH3 architecture, with emphasis on solutions to the more challenging conflicts arising from solver complexity, portable performance requirements, and legacy codes. We also include results from user surveys conducted in 2005 and 2007, which highlight the success of the code.
Deep Dive into Extensible Component Based Architecture for FLASH, A Massively Parallel, Multiphysics Simulation Code.
FLASH is a publicly available high performance application code which has evolved into a modular, extensible software system from a collection of unconnected legacy codes. FLASH has been successful because its capabilities have been driven by the needs of scientific applications, without compromising maintainability, performance, and usability. In its newest incarnation, FLASH3 consists of inter-operable modules that can be combined to generate different applications. The FLASH architecture allows arbitrarily many alternative implementations of its components to co-exist and interchange with each other, resulting in greater flexibility. Further, a simple and elegant mechanism exists for customization of code functionality without the need to modify the core implementation of the source. A built-in unit test framework providing verifiability, combined with a rigorous software maintenance process, allow the code to operate simultaneously in the dual mode of production and development. In
The ASC/Flash Center at the University of Chicago has developed a public domain astrophysics application code, FLASH [11; 5]. FLASH is component-based, parallel, and portable, and has a proven ability to scale to tens of thousands of processors. The FLASH code was developed under contract with the Department of Energy ASC/Alliance Program. It is available to external users through a cost-free licensing agreement. Approved users may download the source code and make local modifications, but may not redistribute the code. FLASH is the flagship Computer Science product of the Flash Center, resulting from over 10 years of research and development.
One of the mandates of the Flash Center was the delivery of a parallel, scalable, and highly-capable community code for astrophysics. Motivation for the code effort lay in the increasing complexity of astrophysical simulations. The traditional academic approach of developing numerical software in piecemeal was deemed inadequate to meet the science needs.
Another aim of the Flash Center was to shift the paradigm of theoretical research towards working in multidisciplinary teams with scientific codes that are developed with modern software practices prevalent in the commercial world. The FLASH code has now reached a level of maturity where it has a large number of users, more than 80% external to the University of Chicago.
Moreover, it also has a substantial number of external code contributors. The number of requests for download, and the number of publications using the FLASH code, have grown superlinearly in recent years (see Section 5). This success was achieved by carefully balancing the often conflicting requirements of physics, software engineering, portability, and performance.
From its inception, FLASH has simultaneously been in development and in production mode. Its evolution into a modern component-based code has taken a path very different from that of most scientific computing frameworks such as Chombo, SAMRAI, CACTUS, and POOMA [8; 24; 6; 13; 14; 16; 21; 19]. Those efforts developed the framework first, followed by the addition of solvers and other capabilities. An alternative path taken by scientific application codes such as Enzo, SWMF, and Athena [20; 23; 12] is to grow into a large application from smaller solvers and applications. Both models of development have their advantages and disadvantages: codes initialized with frameworks have superior modularity and maintainability, while codes begun with solvers generally deliver better performance for their target applications.
FLASH straddles both approaches.
In the first released version, the development followed the solvers-first model, but later versions place more emphasis on modularity, maintainability, and extensibility. The outcome of this duality in development is that FLASH has more capabilities and customizability, and it reaches a much wider community than most scientific application codes. FLASH has gained wide usage because the capabilities of the code have been driven by physics, while its architecture is driven by extensibility and maintainability. The addition of new solvers to FLASH is almost always dictated by the needs of users’ applications. The solvers for multiphysics applications tend to put severe strain on any modern object-oriented software design. Lateral data movement is normally required between different solvers and functional units, which makes resolving data ownership and maintaining encapsulation especially challenging. Also, many of the core physics solvers are legacy thirdparty software written in Fortran, which are rarely modular. While modularity, flexibility, and extensibility are some of the primary guiding principles in the code architecture design, these goals often conflict with the equally important considerations of efficiency and performance. Additionally, since high performance platforms usually have a relatively short lifespan, the need for performance portability places even more constraints on the design process. Achieving a balance between these conflicting goals while retaining the very complex multiphysics capabilities has been the biggest contributor to the widespread acceptance of the FLASH code.
The FLASH model of development and architecture is informed by the literature from the common component architecture effort [15; 2]. Since the project’s inception, FLASH has undergone two major revisions, both of which included significant architectural and capabilities improvements. FLASH has always striven for a component-based architecture, but this goal was not realized in the first version because of a strong emphasis on producing early scientific results using legacy codes. However, foundations for a componentbased architecture were firmly laid in the first version FLASH1.6 [11] by providing wrappers on all the solvers and minimizing lateral communication between different solvers. The second generation versions, FLASH2.0 -FLASH2.5, built upon th
…(Full text truncated)…
This content is AI-processed based on ArXiv data.
