Workshop for High-Energy Physics at UCL

This post originally appeared on the Software Carpentry website.

Following the success of the open bootcamp at UCL in April/May this year, we decided to have a go at introducing some Software Carpentry to the first-year postgraduate students in my own research group, High-Energy Physics (HEP). There is already a longstanding University of London intercollegiate lecture programme for these students, including some programming in C++ and Python. The new workshops aim to help participants consolidate and extend their existing Python knowledge, as well as learning about more general best practice in software development, by following an extended worked example using version control and test-driven development.

In a variation on the "normal" two-day Software Carpentry format, we are running two one-day workshops about a term apart, with the first taking place last Thursday. Attendance was 65% (13 of 20 students) with a single instructor (me) and two other helpers: Sean Brisbane of the Oxford HEP group, where he intends to run something similar, and James Hetherington of UCL's new Research Software Development Team.

Students were able to use their own laptops, or use the provided UCL standard Windows desktop machines to SSH to Linux machines at CERN, UCL or their own institution. It took a while to get the Exceed X server configured appropriately on the Windows machines, and get everyone connected to a suitable Linux machine, which also meant creating accounts on the UCL HEP cluster for students with no other Linux system available.

We used PyROOT so that we could use the ROOT toolkit, which is ubiquitous in HEP, while still programming in Python rather than C++. Predictably there were various problems with incompatible versions of Python and ROOT, but these were all overcome. For version control we used Git, with an emphasis on its use as a personal extended undo facility: we didn't get as far as branching or setting up a shared repository. Nor did we get as far as I had hoped into unit testing, but we did some informal testing in the Python interpreter, and introduced the Python debugger.

Next we will arrange some online tutorials and discussion forums, and use the feedback from these to guide the plan for the second workshop in February.

Pre-workshop survey results

	never heard of it	heard of it but never used it	have used it but don't understand it	use occasionally	use regularly
Bash (or other Unix/Linux shell)				2	11
Python		4	4	4	1
version control	3	4		4	2
unit testing	11	2

Good and bad

Good	Bad
applying Python knowledge	diversity of environments (OS, ROOT, Python versions) causes problems
introduction to version control: wouldn't have discovered how to use it alone	better to have worksheet so can continue while others debug their system if yours is working
learned about XEyes	needed another break in the afternoon
everything covered was new to me	took too long to get everyone set up
enjoyed subject-specific examples	need worksheet so can catch up if behind
good to have an introduction to PyROOT	didn't get far enough into unit testing
helpers were constructive and didn't make us feel like idiots	moved too fast at times
liked tips on readable code