Stuart Prescott

Free software wins and losses in numerical methods education for engineers

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.

User Support Channels BoF

Debian’s focus is on getting a great distribution in front of its users and the importance of the end user is enshrined within our Social Contract. All pieces of software have rough edges and users will always need support to help them make the most out of their available resources.

The environment in which support is provided is important to the user and also to the volunteer who is spending time providing help. In commercial situations the user support job is colloquially known as the “helldesk”, so how do we make it an attractive place for knowledgable volunteers to help out in our project? User support brings together all the best and the worst of the technical and social aspects of free software, offering opportunities for innovative tools to help with user support and also exceedingly negative inter-personal interactions.

In this BoF, we will discuss the channels that Debian currently uses for user support, consider the strengths and weaknesses of these approaches, look for ways to help users find the answers they need to solve the problems they face and also how to better support the volunteers who make this all happen. Spam, trolling, support vampires, BOFHs and burn out will be discussed. The venues to be discussed will include at least mailing lists, IRC, forums, official/unofficial documentation, wiki, and 3rd party websites.