Teaching basic lab skills
for research computing

Workshop for High-Energy Physics at UCL

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 expert
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


Dialogue & Discussion

You can review our commenting policy here.