Scientific computing is one of the oldest, if not the oldest, types of computational science. The venerable Fortran programming language was created to help scientists expand the frontier of what theory could produce as numerical results. In the seven decades of scientific computing, much of the computational work has been done by scientists in physics, chemistry, and other sciences rather than by formally trained computer scientists. Computationally adept scientists may be unaware of the structures of software engineering. This lack of awareness may lead to unnecessary ambiguity and intermingling of the stages of software development, resulting in code difficult to modify and documentation that can be baffling. One of the goals of this paper is to disentangle the steps involved in software development in the sciences to achieve greater clarity in both the software development and in the documentation of the software produced.

The first part of Hinsen’s paper discusses how the conceptual formulation and implementation of a scientific or engineering software package can be shown to follow the traditional software engineering model of “specification, code, and data,” where the mathematical equations governing the physical phenomenon correspond to the specification, the functions implemented are the code, and the numbers generated are the data. The key component is the mathematical model in which the scientific problem is presented--the equations that must be implemented in working code that will produce the numbers that must correspond to experimental observations. He deftly examines how the orbits of celestial bodies can be modeled by Ptolemy’s epicycles, Kepler’s ellipses, and Newton’s gravitational laws. Each can be implemented in a set of mathematical equations, which can be expressed in algorithms, coded into functions, and used to generate numbers that can be compared with those found by direct observation and experiments. The algorithms and functions are realizations of the specifications and are constrained by the specifications. The documentation of the process of generating algorithms and functions is critical for understanding the code and for modifying it. It is the “shop manual” for the software, and it differs from the typical user’s manual describing installation procedures and pull-down menu choices.

The second part of the paper briefly examines alternative mathematical models that go beyond closed-form equations that can be directly implemented as algorithms and functions. These mathematical models include stochastic (Monte Carlo) models, different forms of cellular automata, agent-based models, network models, and neural networks. These can be challenging, especially in explaining how results are obtained and their scope of applicability. It remains a matter of ongoing study to discover how these alternative mathematical models can be integrated into software engineering practice.

This paper should be read closely by those teaching scientific computation and by practitioners who are unacquainted with software engineering. It provides a practical framework for thinking about and doing scientific computation.