Free software wins and losses in numerical methods education for engineers

Track: Ad-Hoc Talks

Type: Short talk (20 minutes)

Video:

Room: Xueshan (雪山)

Time: Aug 02 (Thu), 10:00

Duration: 0:20

Mathematical models allow the designer to optimise and predict, with most engineering curricula containing courses to teach the use mathematical and computational skills to develop, test, and interpret models or simulations. The traditional teaching approach has relied heavily on commercial packages and assumed that students can recall details and integrate concepts from previous years. In this case study, we investigate displacing proprietary tools with free software, look at the effects that has on the community of learners as well as the instructors, and examine the challenges posed to this project by binary distribution through Debian and fragmented/uncoordinated module development.

The teaching of engineering modelling tends to be focused on the use of numerical methods techniques with a small amount of simple programming skills being needed to deliver the required results. Commercial packages such as Matlab are dominant in the teaching of many sub-disciplines of engineering, with institutional or low-cost student licences required. From a teaching perspective, the empty Matlab prompt offers neither assistance nor encouragement to the novice and the path to reconnect model to reality is not encouraged by its raw numerical output; understanding the principles of the model, scepticism based on the “garbage in, garbage out” principle, and robust interpretation of the results are not supported by its user interface. For the scientist and engineer, the mathematics and its embodiment in code are insufficient and there is a strong expectation that translation into words and interpretation are necessary. Jupyter notebooks offer a literate computing environment in which numerical methods and data analysis code can be interactively developed and refined in ‘cells’, while relevant rich context (text, images and equations) is interspersed amongst the code. For the engineer undertaking one-off model development and also for the educational scenario, the Jupyter notebook offers the fusion of code, documentation and output.

To scaffold the three-fold development in programming, numerical methods and discipline knowledge, we have assembled a free software stack based on Jupyter notebooks in which problem statements (in Markdown/MathJax) are accompanied by code cells (in Python or Octave) with some parts of the necessary code to solve the problem redacted, thereby offering hints at how to approach the problems without giving away the entire solution. Within each problem set, progressively less help is offered as confidence and competence is gained. To ease maintenance, both the problem and solution notebooks are generated out of the same annotated precursor notebooks using some simple Python modules we have developed that work with the Jupyter notebook files. Students are: introduced to the concept of free software, offered ways of downloading and installing the tools they will need (Debian shines in this: apt install jupyter), provided with instructor-generated complete examples to analyse and imitate, and given the problem sets on which they can work.

Over the past three years, we have also learnt much about the interplay between the software development/distribution life cycle (scattered upstream releases, updated source packages, binary distribution, deployment) and our own development and delivery cycle (heterogeneous deployments, cloud hosters, strictly time-based releases). For a stable basis on which a course can be built, we prefer Debian stable releases where package versions, features and bugs are a fixed set for the 4 month teaching block; all our development work is done in this environment. How do we then overcome development friction to (say) realise a particularly nifty delivery idea that requires a newer version of the ipywidgets module to add interactivity to the student experience in Jupyter? How do we address a bug with interactive plotting that only exists in one particular combination of module versions that happens to be what is packaged? With such young technology, the tension between ‘latest’ and ‘stable’ plays out each time the course is run, with new features, new bugs and new workarounds to be discovered. We add to this a desire for someone else do the sysadmin work (CoCalc.com as a cloud hoster) and for students to run the code on their own devices, and then problem space becomes significantly larger. In working through the inevitable bugs, the students also see real bug reports, fixes and tests of workarounds, illustrating the power and importance of free software.

In this talk, the benefits and limitations of the chosen tools will be analysed from a software distribution perspective, with discussion of the strengths and weaknesses of Debian’s current approach to packaging the entire stack for binary distribution. The effect of the Debian release model on our teaching and the interplay between Debian and the fragmented upstream communities that are relied upon will be investigated. Some of the capabilities of Jupyter notebooks in the hands of both students and instructors will also be demonstrated.