Workshop on Numerical and Mathematical Software

A D Bryden

1-3 February, 1988

Summary of Recommendations from Workshop on Numerical and Mathematical Software, 1-3 February 1988, University of Warwick

Short Term

1. Do not spend CFC resources on applications-specific packages (examples given were CHAM, PHOENICS), but instead concentrate on the enabling (or "underpinning") software that allows application software to be built.
2. Provide networked information facility on available numerical software, both in the public domain and commercially available. There was some support for this facility also being a repository of software that is of some quality but has not reached the acceptability necessary to be adopted by, for example, Nag. Argonne Lab have experience of this kind of facility. This can be useful, for example, for software that is from USA origins in the public domain, and would reduce the need for transatlantic access. CFC should collaborate with the Computer Board and other SERC Boards in setting up a UK NETLIB.
3. Evaluate the algebraic manipulation packages REDUCE, MAPLE and MACSYMA.
4. Extend the range of software for solution of Partial Differential Equations by purchasing ELLPACK.
5. Make available all Nag's libraries to SERC grant-holders. Nag currently lacks good sparse matrix routines, but that is rectified by their adoption of the Harwell sparse matrix routines. In most cases, where Nag covers an area, its use is recommended - for example GENSTAT and GLIM in preference to SPSS.
6. The workshop's view of of individual programming languages for numerical software was:
   • Fortran 77 at present
   • Fortran 8x and Ada likely to become important
   • C for certain purposes, especially when it becomes ANSI and ISO standard.
   Support these and disseminate guidance on mixed programming, in particular a review of the current state and a list of do's and don'ts.
7. Review and make recommendation (6-9 months) on software standards to bring about common software components, in particular:
   • knowledge-based front ends, with the ability to extract information from large databases
   the
   • (adaptive) mesh generation
   • back ends to post processors covering graphics (including animation, visualisation of 3D objects, and even holography was mentioned! )
8. Review and develop strategy (9 months) for an integrated framework or environment, which would include such aspects as:
   • computational methods
   • symbolic manipulation
   • semi-analytic methods
   • expert systems
9. To improve post-processing:
   • provide graphics software for display of results including 3D representations; it should be possible to take advantage of fast workstations
   • evaluate for the user community, hardware and software for video animation output for analysis purposes in the £lOK-£20K bracket (the intention is for the system to be accessible to the user).

Things to ignore

1. It was felt that support for engineering analysis packages can usually be obtained elsewhere and is not within the remit of CFC. However this was not universally accepted and one group felt that CFC should bring to the attention of other committees the need to provide and support codes for the analysis of fluid flow.
2. There was no support for use of PASCAL.

Longer Term Issues

1. The Workshop recognised that most of the existing pre-processors for FE software are not suitable for the Finite Difference or Finite Volume calculations used in Fluid Dynamics. It identified deficiencies in FE software (also FD and FV needed), surface fitting, boundary elements, large sparse systems, non-linear ODE's (may be rectified by SPRINT), mathematical programming, time-dependent techniques, PDE solvers. CFC should monitor developments of software for solution of FDEs and grid generation, especially use of quantitative error estimation and adaptive techniques.
2. Continue to develop the NAG/SERC FE library and extend its capabilities, especially for non-self-adjoint problems, and in mesh generation and display of results.
3. Implement well-used numerical algorithms (eg linear algebra) on transputer arrays as soon as possible. Use Liverpool transputer feasibility study for guidance.
4. Monitor and research the development of algorithms which are portable across a range of parallel architectures.

Notes

1. There was little or no attempt to cost these recommendations at the workshop because of (a) lack of time, (b) lack of knowledge of software costs. It was suggested that the chairmen of the Working Groups should have a further meeting to finalise these
2. It was recognised that the programme must have sufficient technical and project-oriented content to attract and retain good quality staff.