X Close

Research Software Development


Reliability, readability, and efficiency in scientific software


Archive for the 'Event' Category

How to get started with HPC and AI in your research

Anastasis A Georgoulas28 September 2021

The Tech Socials are back after our summer break, this time with a twist. For September’s social, we decided to follow up on a SeptembRSE event with our own discussion.

The topic was how to get started with technologies like high-performance computing and artificial intelligence. The panel members came from UCL’s Centre for Advanced Research Computing (ARC), research institutes in molecular biology and sociology, as well as industry. We wanted a range of perspectives, and we think we got it!

There’s lots to talk about on this topic and the discussion proved that, as we moved away from practical tips (such as keeping in mind the scale of your data and workloads) to consider the broader context. We covered policy issues, like the availability of seed funding, ideas for tackling the “skills gap” that researchers and students have to overcome, the importance of wrapping your head around what is possible to do with new technologies, all the way to the right attitude, and how technologists can more efficiently communicate with researchers in the social sciences and humanities (hint: some humility is advised).

If this sounds interesting, do watch the recording (unfortunately missing the first few minutes of introductions!). We are still exploring how ARC can best serve UCL, so get in touch if you think we can work together – you can find out more about what we do on the Research Programming Hub pages until the website reflects our change to ARC.

Thank you to all panel and audience members for their contributions!

Our first ever Git workshop online

ucasper16 April 2020

Tl;dr: We successfully ran a 3-hour workshop for 11 learners with one instructor and five helpers. We used Blackboard Collaborate as our main tool and shellshare to “look over the shoulders” of the learners.

Our team has been running training workshops since its start. Enabling researchers to make better software is one of our core goals. Most of our training benefited from The Carpentries’ methodology and material. We were early adopters and supporters of those – UCL became one of the first affiliate institutions of the Software Carpentry Foundation.

These workshops had always been in person, broken into 3-hour blocks with no more than 30 learners at a time, with one helper for at least every seven learners and one instructor per session. That model has been very successful as the feedback from our learners has shown. However, in the current situation where everyone is working from home, we need to move these workshops to the online world. Last week we run our first Git workshop online! We could say it was a success! Keep reading to find out how we did it.

There have been some experiences shared by other groups that we’ve learnt from:

For our first online workshop we had only 11 learners, all from the same research group. This was helpful as they all had similar experience and goals (and that was to learn Git!). We had one instructor and 5 helpers. That made our helpers/learners ratio quite high (from ~1/7 in an in-person workshop to ~1/2), and though that large ratio may not be sustainable for our group, it was safer to start this way.

On the technology side we used a set of tools to facilitate the teaching and helping:

  • To deliver the workshop we hosted the teaching session using Blackboard Collaborate. This is what our university uses for online teaching and it worked very well. Blackboard has various features like sharing the screen, breakout rooms, chat and whiteboard. On this first instance we tried to use the breakout rooms but we didn’t succeed (more about that later). The whiteboard was not used either.
  • Though blackboard has a chat, we also used a google document to share links and other information in a more organised way.
  • Shellshare was used to broadcast the learners’ terminals and each helper was monitoring two of these at a time.
  • We also used Jitsi to host a drop-in session to help with installation issues before the workshop.

Let’s dive into how the organisation and the delivery of the workshop went ahead.


As in any Carpentries’ workshop, we created a quick survey to know how to pitch the workshop. We knew from there that most of the learners were using macOS, only one was using Linux and none were using Windows. That was very useful as we knew that shellshare works well on macOS and Linux.

The students were provided with a set of instructions to prepare for the workshop, and with a suggested way for laying out the windows on a single screen (such as for a laptop). Since there are always problems with installations, we also hosted a one-hour drop-in session a few hours before the workshop. For the drop-in session we used Jitsi as it works straight from the browser with a single link, and a meeting doesn’t need to be scheduled (as in BlackBoard). With Jitsi we could get the learners to share their screen and help them to debug the problems they had.

suggested layout of the windows for a student

We also sent them the link to the google document that we were going to be using during the workshop. In that document, and “copying” from what the SSI had done at the Collaborations Workshop, we included a link to the Code of Conduct, the installation instructions, the Blackboard room, the Socrative room (for quizzes) and the pinup board (for feedback at the end). (We went for a google document instead of a Carpentries’ etherpad so people could include images, though it lacks the ability to refer to a particular line number.)

The workshop

In this workshop we taught the git lesson from software carpentry (with the recipe twist). Therefore, the students were going to use their terminal, nano and GitHub’s website for the last bit.

Almost everyone connected to the digital classroom without issues. Two people had either connectivity issues or problems with the audio; the session was recorded in case they wanted to review it later. We started the session introducing everyone to the platform (how to mute/unmute, raise the hand), how we were going to use the google document and how to start shellshare.

We asked everyone to add themselves with their names and pronouns on the google doc and paste their shellshare link under their favourite helper. Though everyone managed to get a link for shellshare, the success of it was not perfect. Some of the learners switched to use a terminal from within RStudio (leaving the helpers in the dark), or the program crashed at some point. Nevertheless, that didn’t disrupt the workshop much.

We also explained the schedule for the session. We had two breaks every 55 minutes, the first of 10 minutes and the second of only 5. This differs from our common workshops where we have only one break every 90 minutes, but it’s an important change to mention here as people may not have a good chair in their houses and more frequent breaks to stretch are welcome.

Since we knew most of the learners hadn’t used a Unix shell before, we added to the document a short description of the six commands we were going to use (cd, ls, pwd, mkdir, rm and cat) which we introduced during the first 15 minutes of the workshop.

We used socrative to run quizzes during the class, where most of the questions are asked twice, the first one to answer individually and the second one to answer after discussing it with a peer. We tried to translate that to the online world using the breakout rooms capability of Blackboard. However, it didn’t work well. We hadn’t tested before with that many participants in a call and the room creation and assigning people to the room was not as smooth as we would have liked it. In part, this was because we were not too familiar with this tool, but it may also be a limitation of the tool itself (how can we keep the custom assignment of participants to breakout rooms over the whole session?).

During the workshop we had some learners having problems which we tried to help using breakout rooms. The problem there is that the helper loses track of what’s happening in the main room and can’t – as they would do in a physical classroom – point the learner to pay attention to something that’s being explained at the moment, and help after that bit.

Finally, the workshop finished almost on time (+5 min) and we covered most of the material. Learners gave positive feedback and appreciated the number of helpers we had in place.

The instructor setup

I, the instructor, was using a Linux machine running Gnome on Wayland. The terminal that was broadcast was one from within Jupyter-lab. For some reason, the browser could share any application windows except the terminal! (I am yet to understand why.) The terminal was split using Raniere’s shell-split trick letting the students catch up if some commands have gone out of the window. Sharing the terminal via the browser had an unexpected advantage! I could jump between tabs (terminal, google doc, diagrams, github, …) without having to change which application was being shared.

To communicate with the helpers we didn’t define clearly what to do, so we had a Slack room on one side and the moderators’ chat within Blackboard. Thankfully we defaulted to use the chat within blackboard as the workshop progressed.

I had also set up Krita with a drawing tablet in case I needed to use a whiteboard during the workshop. But finally, following Greg’s advice on his talk, I decided not to do so. I had chosen to use Krita instead of the provided whiteboard within Blackboard because I found it harder to write in the latter as it smoothes the lines you draw.

The helpers

The helpers were doing everything within the browser. They were (virtually) looking over the shoulders of some of the learners as they went through via shellshare, informing the instructor to go slower/faster or to intervene if help was needed.

How the helpers were going to communicate with the learners should have been explained better, as the chat of Blackboard was not fully explained and it’s not that obvious!


The workshop was a success! Though we had some hiccups, nothing was too disruptive.

What worked

  • Blackboard is a very nice tool for online teaching, works across all operating systems and doesn’t require any tool or plugin to be installed.
  • shellshare, when it works, is very good!

What could be improved

  • We should have practised setting up break-out rooms on Blackboard more. We would have noticed that the people in each room changes each time you separate them.
  • Explain better to everyone how to use the communication channels (e.g., chat feature on Blackboard)[1].
  • shellshare worked, but not for all. We also need to explain its purpose better (e.g., if a learner uses a different terminal we don’t see it anymore).

Other thoughts

We can’t have this high ratio between helpers and learners, and probably we don’t need as many. Next week we will experiment with one helper for every four students.

Most issues happened at the start. Not everyone installed all they needed beforehand. A “compulsory” drop-in where the setup is checked and explained will give more time to focus on the content of the lesson. Additionally, a self-check script, as in the carpentry workshops, that tells whether the installation has been successful would help.

The learners at this workshop were familiar with RStudio (but we didn’t know it). Maybe teaching git from within RStudio would have worked better, although it would require more space on the learner’s window as the IDEs are bigger than a terminal.

In this workshop we didn’t have anyone with Windows. Shellshare by default doesn’t work for Windows, but there’s a workaround using Powershell and with Python installed.

Using shellshare you may wonder whether you are streaming passwords when using it. The answer is no. Shellshare uses the UNIX command script and only stores what you see on the screen.

How well did we do regarding the recent Carpentries’ recommendations for teaching workshops online?

  • experienced instructor and small class size ✅
  • procedures that are as close as possible to our standard practices ✅
  • The most common barriers are likely to be unreliable internet connections (the workshop was recorded) ✅
  • and the limitation of a small single screen (suggested windows layout) ✅
  • pre-workshop support with software installation ✅
  • and the use of cloud instances with pre-installed software as a backup ❌
  • Helpers: Stepping in if Instructor loses connection ❌

That document provides many more recommendations. I think we did very well with most of them, but we can still do better!

One day we will be as prepared as this Chris at Berkeley


  1. It turns out that on Blackboard you need to click a back arrow on the top of the chats to exit from the “Everyone” chat! ↩︎

Career opportunities for RSE-like roles outside RSE groups

Jonathan Cooper23 August 2019

In the weeks running up to the RSE Conference, myself and some colleagues will be providing our thoughts on the questions people have submitted for our panel discussion with senior university management about how RSEs are being supported within academia. (You can submit more questions and vote on the current questions on Sli.do.)

Question: If you have a central university RSE group do other staff working in RSE-like roles in academic departments have the same career opportunities as that group?

As research software groups grow, seemingly inevitably they start to acquire more structure and hierarchy, with more senior roles being created to help manage the group. This provides for career advancement opportunities within the group, although often this is with the caveat that an increase in grade requires more managerial responsibility and reduced time for technical work. The situation is more bleak for those employed directly in research groups, typically on a fixed-term postdoc style contract where typical academic advancement routes – dependent on a publication record – do not easily apply. How can universities ensure the same opportunities are available to all staff?

Several groups have tried to address this challenge by making their job descriptions and selection criteria available to the whole university, for instance at Sheffield and King’s Digital Lab. This promotes consistency of approach, and gives the potential to aim at senior roles with appropriate selection criteria. Sustaining posts beyond a single funding source still presents a bottleneck to supporting careers, however. Central RSE groups with a large project portfolio and successful track record can often offer permanent contracts to staff, whereas this is rarely an option for individual research groups. At UCL we are investigating the potential of establishing ‘satellite’ groups within academic departments. These would be able to offer equivalent terms and conditions to their staff, and collaborate closely with the central team. We are not there yet however!

It is also worth considering a broader perspective. For staff trapped in a succession of fixed term contracts, ‘career opportunities’ is often synonymous with getting a permanent post, ideally at senior postdoc or even up to professorial pay grade. There are however many directions of travel that could be considered. How do we allow university staff, wherever they may be based, to move flexibly between teaching, research and professional services roles (or a combination thereof!), into industry and back into academia, always learning new skills along the way? How can progression be linked to expertise in different technical areas, not just management responsibility?

This question is ultimately not limited to RSE roles, but affects the wider network of roles within academia. UCL’s career pathways initiative (aimed at professional services) and academic career framework provide hopeful first steps in supporting more flexible careers, but there is still plenty of work to be done!

Hear an expert perspective on this and a variety of other questions from a panel of senior institutional representatives covering roles in research, HR and research software at the Science and Engineering South panel on “Institutional Support for RSEs” at RSEConUK19 on the 18th September at 13:30. You can also read previous blog posts in this series by Simon Hettrick and Jeremy Cohen.


Jonathan Cooper28 September 2018

Back in early September was the third edition of a series of conferences dedicated to Research Software Engineering.

It’s like the national meetings that exist for numerous disciplines, but to talk about us: our community and career paths, ways to serve the research community better, tools and techniques for better software, among others. As expected, almost the whole Research Software Development Group (and Ian Kirker from Research Computing!) attended the conference.

This year’s conference was really important for us: the conference started with a keynote by our very own Prof. Eleanor Robson of UCL Archeology, who talked about Oracc, the longest project our group has been involved in since its creation, including a couple of demos of the tools we have created for writing translations of cuneiform texts. We had Ilektra Christidi in the organizing committee, who also co-organized and co-chaired the international session, a lively event where RSE’s from around the world exchanged views and experiences from the communities of their countries, and discussed about cross-country initiatives and collaborations. Tom Dowrick – our affiliated team member – gave a talk about using the Robot Operating System to create a reproducible platform for surgical device development.

As usual, there were interesting workshops and talks from researchers, RSEs and representatives of big industry players alike. We especially enjoyed the workshops about singularity; JupyterHub + kubernetes; lean tools for product development; and parallelizing python applications. Talk highlights covered building computer vision systems by Microsoft Research; why making scientific software sustainable is difficult; GUI’s and visualization; lessons from CASTEP on rebuilding legacy software; and an entertaining and enlightening presentation from Catherine Jones (STFC) on how to shut down services gracefully – something we’ll be putting into practice as we deprecate our local Jenkins service in favour of the national service STFC are now piloting.

There was also exciting news for the future of RSE in the UK, with the announcement of a new registered society due to be launched soon. And we are excited to have struck up an agreement with the Software Sustainability Institute to collaborate with them on analysing their international survey results – more news on that in the coming months!

Our group head Jonathan Cooper attended several sessions looking at different aspects of managing RSE groups, as well as having many stimulating discussions with other RSE group leaders. There was a helpful workshop on inclusivity and diversity in RSE recruitment, discussing everything from wording of adverts to structure of interviews – and indeed how we maintain a welcoming culture within our team. UCL is doing well in so far as we have 6 nationalities within the team, 40% of our senior team female, and have put together majority-female interview panels, but there is no room for complacency. We’ll be looking at what outreach we can do to demonstrate what a great career path RSE is for all people. A panel session with RSE group leaders highlighted that all RSE groups across the UK face much higher demand for their services than they can match with current staffing levels, and so training the next generation of RSEs will be crucial.

A funders’ perspective from Susan Morrell (EPSRC) and David Carr (Wellcome Trust) underlined again the increasingly heavy dependence of UK research on software development, and hence the need for RSEs. Wellcome’s emphasis on open research was particularly encouraging. Also of interest here was an ARCHER study showing a 3:1 return on investment for their eCSE programme, which provides RSE support to researchers using national HPC resources. In another session we thought about ways in which RSE groups can benefit the wider community: not just delivering projects which benefit the researchers involved directly, and ensuring these tools are usable by others, but contributing to underpinning open source projects on which many researchers depend.

All in all, enough technical and social activity – a good warm up as term begins and we resume our regular activities, like drop-ins, Tech Socials, and coffee mornings!

Seminar: Developing a Parallel Adaptive Method for Pseudo-Arclength Continuation

cceajhn14 August 2013

There will be a seminar in the “research programming in practice” series by Dhavide Aruliah University of Ontario Institute of Technology (Oshawa, ON, Canada) on Weds 28th August at 2pm in Drayton B06.

Pseudo-arclength continuation is a well-established framework for generating a curve of numerical solutions of nonlinear equations. In my talk, I will review the basic ideas underlying adaptive predictor-corrector schemes for pseudo-arclength continuation emphasising where the bottle-neck arises in computation of rejected corrector steps. We have been developed a parallel code using standard C and MPI for adapting the step-length in pseudo-arclength continuation. Our method employs several predictor-corrector sequences run concurrently on distinct processors with differing step-lengths. Our parallel framework permits intermediate results of unconverged correction sequences to seed new predictor-corrector sequences with longer step-lengths; the goal is to amortise the cost of corrector steps to make further progress along the underlying numerical curve. I shall describe the essence of the parallel code and some of the issues that arose in its implementation. The goal is to have a straightforward interface to an MPI library into which researchers can plug in their serial C continuation codes to achieve modest improvements with widely available multicore desktop machines. This is joint work with Alexander Dubitski (Amadeus R & D, Toronto) and Lennaert van Veen (UOIT).

James P J Hetherington8 August 2013

Another workshop which I will be at, which should be of interest to readers:

Research software engineers are the people behind research software.
They not only develop the software, they also understand the research
that it makes possible.

Software is a fundamental part of research, and research software
engineers are fundamental to good software. Despite this, the role is
not well understood in the research community. This is something the
Software Sustainability Institute is campaigning to change – starting
with a workshop for research software engineers.

We will bring research software engineers together to talk about new
tools and interesting work, to share ideas with people who do the same
work, and to discuss how we can overcome the problems that are faced by
all research software engineers – like gaining recognition and reward
for their work.

The term research software engineer is new, so many people who fulfil
the role will not describe themselves in this way. To help judge whether
you should attend the workshop, we’ve put together some questions:

1. Are you employed to develop software for researchers?
2. Are you a researcher who now spends more time developing software
than conducting research?
3. Are you employed as a postdoctoral researcher, even though you
predominantly work on software development?
4. Are you the “person who does computers” in your research group?
5. Are you not named on research papers despite playing a fundamental
part in developing the software used to create that research?
6. Do you lack the metrics needed to progress your career in research –
like papers and conference presentations – despite having made a
significant contribution with software?

If you answered yes to any of the above questions, you should attend the
workshop for research software engineers.

For more information:
Registration: http://workshopforresearchsoftwareengineers.eventbrite.co.uk/

First Workshop on Sustainable Software for Science

James P J Hetherington29 July 2013

The below workshop may be of interest to readers: I will be there.

First Workshop on Sustainable Software for Science:
Practice and Experiences (WSSSPE)

(in conjunction with SC13)
Sunday, November 17, 2013, Denver, CO

Progress in scientific research is dependent on the quality and accessibility of
software at all levels and it is now critical to address many new challenges
related to the development, deployment, and maintenance of reusable software. In
addition, it is essential that scientists, researchers, and students are able to
learn and adopt a new set of software-related skills and methodologies.
Established researchers are already acquiring some of these skills, and in
particular a specialized class of software developers is emerging in academic
environments who are an integral and embedded part of successful research teams.
This workshop will provide a forum for discussion of the challenges, including
both positions and experiences. The short papers and discussion will be archived
as a basis for continued discussion, and we intend the workshop to feed into the
collaborative writing of one or more journal publications.

Seminar: When The Software Sustainability Institute Met MICE

James P J Hetherington1 May 2013

The next installment of the Research Programming in Practice series will be by Mike Jackson. Mike is a software architect at the Edinburgh Parallel Computing Centre at Edinburgh University, and provides consultancy and training as part of The Software
Sustainability Institute. The event will take place on Tuesday 14th May at 3:30pm, in Roberts 309.

The Software Sustainability Institute is a UK facility which promotes better research through better software. We seek to shape UK research policy around software, engage with research communities, provide training in software development to researchers and to provide consultancy to specific research projects.

In this talk, I’ll give an introduction to The Software Sustainability Institute and an example of one of our successful collaborations – with MICE, the Muon Ion Cooling Experiment. MICE is a UK-based international collaboration of around 100 particle and accelerator physicists. The collaboration is based at the Rutherford Appleton Laboratory and are working on a fundamental component of a proposed neutrino factory. MAUS (MICE Analysis User Software) is a modular, data-analysis package that provides a framework in which various MICE software functionality can communicate. MAUS is designed to support both online analysis of live data and detailed offline data analysis, simulation, and accelerator design.

I’ll describe how we worked with MICE to provide consultancy on how they could manage their software development, review their online resources from a sustainability perspective, and contribute to extending MAUS to support distributed job execution and analysis.

This will be an exciting opportunity to learn about the work of the SSI, who do great work to improve the quality and longevity of research software throughout the UK. (Disclosure: I’m an SSI Fellow.)

Seminar: Unit testing C++ code for use in Medical Imaging

James P J Hetherington12 February 2013

As part of the Research Programming in Practice seminar series, Matt Clarkson from the UCL Centre for Medical Image Computing will be speaking on “Unit testing C++ code for use in Medical Imaging.”

The seminar takes place on Tuesday 26th February, at 10am, in room 421 in the Roberts building in UCL.

Please forward the invite to groups you believe may be interested, and sign up for further notifications of seminars in this series via https://www.mailinglists.ucl.ac.uk/mailman/listinfo/research-programming.

Seminar: Obtaining research credit for creating software.

James P J Hetherington23 January 2013

As part of the “Research Programming in Practice” seminar series, Brian Hole , founder of Ubiquity Press and creator of the Journal of Open Research Software will be speaking about a thorny problem for computationally-focused researchers: how do you best build a publication record and enhance your academic reputation when your primary output as a researcher is software?

The Journal of Open Research Software is one potential solution, associating a software entity with a peer-reviewed journal publication. (Disclosure: I’m on the Editorial Board of JORS)

This will be an exciting event, and I’m sure there will be plenty of discussion about this difficult issue for computational researchers.

The seminar takes place on Tuesday 12th February, at 10am, in the B15 Lecture Theatre in the Darwin Building.