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 70 th birthday

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

3. July 1972

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 don’t 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]logical argumentcourse of actiondecision judgment

7. Six tacit assumptions that drove the field from the 1960s

8. Assumption 1 Scientists and engineers develop their own mathematical simulation codes.

9. Today’s 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. Today’s 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

17. Today’s 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. Today’s Reality This started to change with the coming of the PC. With today’s 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. Today’s 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. Today’s Reality Problem characteristics in a particular simulation may dictate algorithm variations that don’t 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