Tacit Assumptions in the Field of Mathematical Software

1
Tacit Assumptions in the Field of Mathematical
Software

• Albert M. Erisman
• Seattle Pacific University
• Dedicated to John K. Reid
• at the celebration of his 70th birthday

2
Overview

• Two stories
• Six Assumptions and their implications
• Some questions for those working in the field of
  mathematical software

3
July 1972
4
(No Transcript)
5
The Model for Mathematical Software (User
Viewpoint)

• I need to build a mathematical model
• The algorithm at the heart of the model is
• The most complex part of the simulation
• The part that drives performance and reliability
  of the entire simulation
• By using a standard piece of mathematical
  software rather than writing this part of the
  code myself, I can
• Save time and money
• Improve the reliability of the simulation
• Draw on expertise I dont have
• Early weakness in that model
• Mathematical software was primarily shareware
• Often it was questionable in its performance and
  reliability
• These factors led to the field of mathematical
  software

6
Tacit Assumptions

• A tacit assumption or implicit assumption is an
  assumption that includes the underlying
  agreements or statements made in the development
  of a logical argument, course of action,
  decision, or judgment that are not explicitly
  voiced nor necessarily understood by the decision
  maker or judge. Wikipedia

7

• Six tacit assumptions that drove the field from
  the 1960s

8
Assumption 1

• Scientists and engineers develop their own
  mathematical simulation codes.

9
Todays Reality

• For most standard computations (structures,
  electromagnetics, electronics, chemical process
  simulation, linear programming, ) most
  scientists and engineers use standard software
  developed in their fields enabling
• commonality and comparison of results
• cost and time savings
• The mathematical software in that simulation is
  largely invisible to the user

10
Questions for Mathematical Software Developers

• Who is the customer for the mathematical
  software?

11
Assumption 2

• Mathematical software was exchanged for free.
• There were no were no intellectual property
  issues,
• This software could readily be used as building
  blocks for larger simulations.

12
The Transition

• IBM started the trend limiting distribution of
  math software in 1969
• The change created a business opportunity for
  mathematical software libraries (NAG, IMSL)

13
Todays Reality

• A great deal of this software both costs money
  and has IP restrictions on its use.
• IP restrictions often inhibit the use of the
  mathematical software in the resulting simulation
  code.

14
Questions for Mathematical Software Developers

• If reuse (and remix) is the goal, are the
  standard practices for the distribution of
  software standing in the way of its reuse?
• How do these realities get taken into account in
  the distribution and restrictions on mathematical
  software?
• If the software is exchanged for free without
  restriction, who pays the salaries of the
  developers?

15
Assumption 3

• Mathematical software was designed for scalar
  computers.
• Reducing the computation time for the
  mathematical software directly translated into a
  reduction in computational time for the
  simulation.

16
Simulation Performance
Algorithm performance
Algorithm performance
17
Todays Reality

• Mathematical simulations on parallel computers
  raise new questions.
• Should the algorithms be optimized for the
  parallel computer, or should the simulation be
  optimized?
• Are these the same?

18
Questions for Mathematical Software Developers

• Should the algorithm developer try to achieve
  maximal parallelization for the algorithm, or
• Should the developer create software that will
  support the best parallelization of the resulting
  simulation code?
• What other issues should we be thinking about?

19
Assumption 4

• Mathematical software was primarily used in
  simulation applications run on mainframe
  computers (and vector computers).
• The changes in this hardware could be readily
  applied to the libraries, simplifying the
  challenge for the user in migrating his or her
  code from one machine to another.
• The frequency of use of the mathematical software
  could easily be measured on the mainframes.

20
Todays Reality

• This started to change with the coming of the PC.
  
• With todays powerful microchips and larger
  memories, mathematical simulations are done on
  all kinds of devices including hand held and
  onboard.
• The architectures are very diverse leading the
  challenges in creating standard code with ideal
  performance across these platforms.

21
Questions for Mathematical Software Developers

• How might the mathematical software be
  distributed and managed in such a way that users
  can tailor it for their own environments?
• Who troubleshoots problems with the software when
  a user changes the code?

22
Assumption 5

• Mathematical software was generally written in
  Fortran or Algol, since most scientific
  computation was done in these languages.

23
Todays Reality

• The diversity of platforms may call for many
  versions (and languages of implementation) of the
  same algorithm
• No single version, even with machine dependent
  adaptations, may be suitable.

24
Questions for Mathematical Software Developers

• Questions of tailoring and troubleshooting
  persist as the software is adapted to different
  computing environments and programming languages

25
Assumption 6

• The structure of libraries was driven by a
  mathematical taxonomy special functions,
  solution of linear algebraic equations, curve and
  surface fitting, ordinary differential equations,
  etc.
• Completeness of coverage could be measured by the
  most commonly used entries in this taxonomy
  without too much knowledge about the details of
  the various simulations.

26
Todays Reality

• Problem characteristics in a particular
  simulation may dictate algorithm variations that
  dont neatly fit the general purpose
  mathematical taxonomy
• Complex symmetric (not hermitian) matrix
  solutions
• Sparse matrices with specific patterns
• Fixed step ODE solvers
• Very specialized curve and surface fitting tools

27
Power Systems Transient Stability
Data Input
Solution of System of Nonlinear ODEs
Summarize Results
Graph Results
Solving the sparse Linear systems at the inner
loop of the ODEs
28
Learnings from this Work

• Engineers tended to use fixed step integrators
• They rarely updated the Jacobians
• This inside knowledge led to fast and accurate
  solutions

29

• Simulation

Library
30
Questions for Mathematical Software Developers

• How is an external library adapted to specific
  applications contexts, where that library may
  need new functionality driven by specific
  applications?
• How does a library organize and support important
  but non-standard algorithms?

31
Comment

• Assumptions 2 (IP issues), 4 (diversity of
  environments) and 6 (specialized requirements)
  kept us from adopting a commercial library as our
  foundation at Boeing. We studied the issue four
  or five times from 1980 till 2001.

32
Continued Need

• In spite of the changing assumptions in the field
  of mathematical software, the need for
  mathematical software persists and grows
• Once confined to simulations, math software is
  now at the heart of robotics, elevator
  operations, flight controls, GPS devices, etc.
• However, the world in which this software is
  needed is much more complex, with
• Many users migrating to off the shelf software
• New applications requiring non-standard
  algorithms
• Significant reuse questions
• Diverse environments challenging the measure of
  use, standards of delivery, and the stability of
  the software

33
Conclusions

• Mathematical software was started with a
  collection of tacit assumptions in the 1960s
• These assumptions are no longer valid
• As in the case of land ownership and airplanes,
  or IP issues and remix capability, this calls for
  rethinking basic issues
• I offer these questions for your consideration

34
Acknowledgments

• I would like to thank Thomas Grandine from Boeing
  for help in the preparation of these ideas
• Ronald F. Boisvert, Mathematical Software Past,
  Present and Future, Mathematics and Computers in
  Simulation, vol. 54, 2000, pp. 227-241
• Unknown remix artist