-The software lifecycle is a well-researched topic that has produced many models to meet the needs of different types of software projects. However, one class of projects, software development for scientific computing, has received relatively little attention from lifecycle researchers. In particular, software for end-to-end computations for obtaining scientific results has received few lifecycle proposals and no formalization of a development model. An examination of development approaches employed by the teams implementing large multicomponent codes reveals a great deal of similarity in their strategies. This paper formalizes these related approaches into a lifecycle model for end-to-end scientific application software, featuring loose coupling between submodels for development of infrastructure and scientific capability. We also invite input from stakeholders to converge on a model that captures the complexity of this development processes and provides needed lifecycle guidance to the scientific software community.
I. INTRODUCTION
The software lifecycle is a well researched topic with
copious literature and many models that serve the specific
needs of different type of projects. The objective behind the
definition of lifecycle models is to decompose the software
development process into distinct stages, where each stage can
control its own quality and result in higher quality software
overall. Examples include waterfall [
Codes for simulation and analysis are typically used either
to understand some phenomenon or process through
computational exploration or to help design physical experiments and
instruments for similar investigations. These codes often tend
to be interdisciplinary endeavors and need more lifecycle
elements because they have to contend with many stages that have
different levels of complexity. Among scientific simulation
codes exists a class of codes that are multiphysics, multiscale,
and multicomponent [
In this idea paper we outline the elements of various
relevant lifecycle models and use them to create a software
lifecycle model that meets the needs of software for scientific
simulation and analysis. As previously mentioned, variations
of the model are already in use in many projects without a
formal theoretical basis [
II. SCIENTIFIC CAPABILITY DEVELOPMENT CYCLE The first phase of a typical lifecycle model is requirement gathering—a complex undertaking for science research codes that deserves its own model. Scientific software is designed to model phenomena in the physical world, including physical, chemical, or biological processes or their combinations. Scientific experts interested in studying such phenomena formulate a mathematical model that captures the behavior of the system as they understand it. The model may not be complete or fully understood. Because most models do not lend themselves readily to analytical solutions, the mathematical model is discretized so that numerical methods may be applied to find one or more solutions.
Figure 1 shows a schematic of the process in scientific software development that is equivalent to requirement gathering. This example is taken from the development of a model based on partial differential equations. The stages roughly follow the process described above, where the first step is formulating the mathematical model. If the model is simple, the second stage of incorporating approximations may not be needed, although more often approximations are used. Sometimes approximations are introduced to make a model tractable, while in other cases approximations save computation time and may not make a substantive difference to the simulation outcome. In still other cases approximations are used because the corresponding part of the model may not be well understood. The next two stages are discretization and algorithm development. Existing implementations of the needed algorithms in third-party software or libraries may obviate the need for the algorithm development stage. In such situations convergence and stability analysis may not be needed. Once an implementation is available, the computational model should be validated against some calibrated observation. The calibration stage is where the range of valid operation of the model is tested against the implementation. While not every project requires a calibration stage, this phase is often critical.
Figure 1 shows feedback arrows from the validation stage
to three of the earliest stages. The process of verification and
validation may reflect a need to adjust approximations because
some approximations may lead to too much compromise on
model fidelity, or it may be found that more approximations
can be made without substantive loss of fidelity. Similarly
a numerical algorithm may prove to be inadequate or too
expensive for the region of interest, or the implementation
choices may make it suboptimal. Any of the these situations
can lead to resetting the state of the development to the
corresponding stage and resuming the cycle from that stage.
Thus, scientific code developers work iteratively [
Valida7on Calibra7on Valida7on Mathema7cal Model Correctness Stability Convergence
Approxima7ons Discre7za7ons
Numerical
Algorithms Target Phenomena Mathema7cal Model Correctness Stability Convergence
Approxima7ons Discre7za7ons
Numerical Algorithms
Valida7on Numerical Library Fig. 1. Schematic of requirement gathering and prototype development in scientific simulation codes Fig. 2. Schematic of prototype development when the model needs more than one component. Here one component needs a new numerical algorithm, while the other component is using a library. Discretization is the same.
A change in discretization is rare for a component, and hence the arrow is dashed. The other dashed arrows represent the possibilities of bypassing some of the stages. For example, if calibration is not needed, the stage is bypassed for validation. Similarly, if a third-party or library-based numerical algorithm is used, convergence and stability analysis of the algorithm may be unnecessary. In multicomponent codes this kind of cycle may exist independently for different components, or some of the components may share a part of the cycle. Figure 2 shows an example of a partially shared cycle between two components with the same discretization. One component needs calibration and a new algorithm, while the other component can use a preexisting numerical algorithm Simula5on Analysis Planning Code
Calibra5on Valida5on
Mathema5cal Model Correctness Stability Convergence
Approxima5ons Discre5za5ons
Numerical Algorithms Infrastructure
CapabiliBes
Requirements So.ware Architecture API Design
Implement
Test Maintain Augment
Model
API
Design
Develop
Validate
Integrate
and needs no calibration. Figure 3 shows the development
cycle augmented with the needs of simulation planning and
results of scientific discovery. See [
III. INFRASTRUCTURE DEVELOPMENT CYCLE
Because the development of scientific software usually responds to an immediate scientific need, the codes typically are employed in production as soon as they have a minimal set of capabilities for some simulation. Similarly, the development of computational modules almost never stops through code lifecycles because new findings in science and math almost continuously place new demands on the codes. While the additions may be incremental when they incorporate new findings into existing features, the additions are often substantial when new capabilities are added. The need for new capabilities may arise from the need for greater model fidelity or from trying to simulate a more complex model. Sometimes a code designed for one scientific field may have enough in common with another field that capabilities may be added to enable its use for the new field.
Irrespective of the cause, coexistence of development and production/maintenance phases is a constant challenge to code Fig. 4. Infrastructure development cycle and its coupling with the scientific capability development cycle. teams. While numerical algorithms and solvers can be in a continually evolving state that reflects the advances in their respective fields, fundamentals such as discretization methods, I/O, and other similar supporting services generally are much more stable from the perspective of application scientists. While separate components for support services may not be needed for simple codes with one or two capabilities, separate support services are critical in codes with many capability components that must interoperate with each other and work as a whole. Extracting support services into common infrastructural components is the only way to make the development tractable for such codes. Note that common infrastructure does not imply that every capability must adhere to the same discretization or the same form of I/O or runtime support. Instead, all different manifestations together form the overall infrastructure or backbone of the code.
The lifecycle model for infrastructure development can be any of the prevalent models mentioned in Section I, depending on what is best suited for individual projects. Among scientific communities, the agile model is most popular because even infrastructure is not completely devoid of incremental changes. Not all agile methods apply, but the philosophy of the methodology is well suited to codes that are constantly evolving. The overall development model for such software needs to incorporate coupling between the two modes of development. One possible solution is shown in Figure 4.
In this coupled lifecycle model, a large part of the development cycle of each type (infrastructure and scientific capability) proceeds independently of the other. API design, integration, and integrated testing and maintenance are the coupling points between the two modes of development. We have added a stage for augmentation over and above the usual stages in the infrastructure model to account for incremental changes that are integral to all large scientific projects. The augmentation stage also makes provisions for any changes imposed on the infrastructure when a new scientific capability integrates into the existing code or an existing capability imposes some new constraints due to its own tweaking. Good software discipline requires that different components interact with one another through APIs; therefore that is another coupling point between the two development cycles. A new scientific capability may demand augmentation of the infrastructure API or recognition of the API of the new capability. Both kinds of modification to the API should proceed cooperatively.
IV. DISCUSSION
This proposed development cycle is meant to serve as a
starting point for a meaningful discussion about the unique
needs of scientific software, in particular multiphysics,
multicomponent simulation software that runs on HPC resources.
This lifecycle model does not capture some of the other aspects
of software engineering that are unique to such software.
For example, testing of scientific software needs to reflect
the layered complexity of the codes. A single box “testing”
in the model does not adequately capture that. Similarly,
porting a code to new platforms can be a challenging
undertaking requiring substantial development resources (see [
ACKNOWLEDGMENTS
This work was supported by the U.S. Department of Energy Office of Science Office of Advanced Scientific Computing Research.
The submitted manuscript has been created by UChicago Argonne, LLC, Operator of Argonne National Laboratory (Argonne). Argonne, a U.S. Department of Energy Office of Science laboratory, is operated under Contract No. DE-AC0206CH11357. The U.S. Government retains for itself, and others acting on its behalf, a paid-up nonexclusive, irrevocable worldwide license in said article to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government. The Department of Energy will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan. http://energy.gov/downloads/doepublic-access-plan.