Software and research: the Institute's Blog

Collaborative Lesson Development: teaching data on the web at MozFest 2014

By Aleksandra Pawlik, Training Leader.

After 2013's success of running the session on "What makes good code..." the Institute helped in running another session at this year's Mozilla Festival. The focus of the session was on "designing open lessons on Teaching Data on the Web by filling in gaps between current workshop offerings, and building domain-specific content."

The session was originally proposed by Data Carpentry with Karthik Ram (ROpenSci) as the main facilitator. Karthik was supported by Robert Davey (The Genome Analysis Centre), Milena Marin (School of Data), Billy Meinke (Creative Commons) and myself. The objectives of the sessions were not only to create and improve the existing Data Carpentry materials for teaching data on the web but also to familiarize the participants with the process of collaborative work on these materials.

Improved code for ARCHER hits the target

Shoot that poison arrow to my hearrrrr-rrrrt...By Gillian Law, TechLiterate, talking with Prashant Valluri, University of Edinburgh.

This article is part of our series: Breaking Software Barriers, in which Gillian Law investigates how our Research Software Group has helped projects improve their research software. If you would like help with your software, let us know.

There's a difference between writing code and writing good code, says Prashant Valluri, Lecturer at the University of Edinburgh's Institute for Materials and Processes, laughing as he describes how much he learned while working with the Software Sustainability Institute.

Valluri's team has developed code called TPLS (Two-Phase Level Set), for mathematically modelling complex fluid flows. The code aims to provide much more effective computational fluid dynamics (CFD) analysis for academia and industry, by providing efficient multi-phase models, better numerical resolution and efficient parallelisation.

Researchers both rely on software - and overlook it

By Simon Hettrick, Deputy Director.

This article originally appeared in Research Fortnight.

With few exceptions, every significant advance in research over at least the past 30 years would have been impossible without computer software. Research software—used to produce results rather than for, say, word processing or web searches—has spread far beyond traditionally computational fields such as particle physics and bioinformatics to achieve near ubiquity in all disciplines. In my role at the Software Sustainability Institute, I have worked with everyone from fusion physicists to choreographers.

The institute, which helps researchers with software and promotes a better understanding thereof, is conducting a survey of researchers selected at random from 15 Russell Group universities. Early indications from about 400 respondents are that almost 90 per cent rely on research software. About 70 per cent report that their research would be impossible without it, and almost 60 per cent develop their own software.

Why is a software petition important?

By Simon Hettrick, Deputy Director.

Two weeks ago, we launched a petition to see how many people agreed that software is fundamental to research and, if we overlook this fact, that we lose our ability to make groundbreaking discoveries. How will the petition help make a difference?

The purpose of the petition is to raise awareness of research software. Every person who signs, everyone who retweets and - importantly - everyone who talks about the petition in their groups or offices, helps make more researchers think about their use of software. The more of those people who sign up, the easier it is to persuade research stakeholders that they must change their policies to support software. And that's not just research funders in the UK, research funders in the Australia, Canada, Germany, Netherlands, New Zealand, Poland and the US are currently working with us to develop similar policies in their own countries.

£840 million: the UK's investment in software-reliant research in 2013

By Simon Hettrick, Deputy Director.

Over the last few months, we’ve been working on improving our understanding of the size of the research software community. In previous posts, I’ve discussed our plans for this research. Although we've not yet finished our analysis, we thought that it would be interesting to release some early results. First of all, how much money do the Research Councils invest into research that relies on software? The answer: at least a third of the entire RCUK budget - or £840 million in 2013.


The UK Research Councils and Technology Strategy Board (TSB) have been investing, at a minimum, around 30% of their total budget for project grants into software-reliant research, which is £840 million in the financial year 2013-14. We expect the actual investment to be significantly larger than this figure due to the fact that software is rarely discussed in the title or abstract of a grant - data on which this research relies.

Seventeen authors, four weeks and one reproducible paper (we hope)

By Steve Crouch, Research Software Group Leader, Ian Gent, Alexander Konovalov and Lars Kotthoff.

Reproducibility is a cornerstone of science, and the first Summer School in Experimental Methodology in Computational Research in August at the University of St Andrews explored the state-of-the-art in methods and tools for enabling reproducible and "recomputable" research.

This included a couple of sessions presented by the Institute on the importance of reproducibility and sustainable software development. However, this School took the notion of reproducibility to a novel extreme. Not only can the technical exploratory case studies be reproduced by others, but a paper jointly written by the organisers and participants during the week that includes these results can be reproduced as well.

Introducing the Open Science Peer Review Oath

Magna CartaBy Neil Chue Hong, Director.

One of the foundations of the scientific method is to be able to reproduce experiments and corroborate the results of research that has been done before. However, with the increasing complexities of new technologies and techniques, coupled with the specialisation of experiments, reproducing research findings has become a growing challenge. Clearly, scientific methods must be conveyed succinctly, and with clarity and rigour, in order for research to be reproducible.

With the Open Science Peer Review Oath, a group of researchers, editors and publishers (including Institute staff and collaborators) have proposed steps to help increase the transparency of the scientific method and the reproducibility of research results: specifically, to introduce a peer-review oath and accompanying manifesto. These have been designed to offer guidelines to enable reviewers (with the minimum friction or bias) to follow and apply open-science principles, and support the ideas of transparency, reproducibility and ultimately greater societal impact.

Desert Island Hard Disks: Andrew Treloar

You find yourself stranded on a beautiful desert island. Fortunately, the island is equipped with the basics needed to sustain life: food, water, solar power, a computer and a network connection. Consummate professional that you are, you have brought the three software packages you need to continue your life and research. What software would you choose and - go on - what luxury item would you take to make life easier?

Today we hear from Andrew Treloar, Director of Technology at the Australian National Data Service and Co-chair of the Research Data Alliance Technical Advisory Board.

I still can't quite remember how I ended up on the desert island... It may have been a particularly bad performance review, or possibly my boss just took me a bit too seriously when I said I needed more time to sit and think? In any case, the only bit of the process that is still clear in my memory was having a short window in which to decide which device to take and what software packages I was allowed to load onto the internal flash storage. (Hard disks? Who uses hard disks anymore?)

Magnetic imaging software now FABBERlously easy to use

By Gillian Law, TechLiterate, talking with Michael Chappell, University of Oxford.

This article is part of our series: Breaking Software Barriers, in which Gillian Law investigates how our Research Software Group has helped projects improve their research software. If you would like help with your software, let us know.

Sometimes you just have to recognise that you can’t do everything, acknowledge that someone else has more experience and skills than you do, and accept their help.

That’s what Michael Chappell, Associate Professor in Engineering Science at the University of Oxford’s Institute of Biomedical Engineering did, when he turned to the Software Sustainability Institute for a steer in how to take his software forward.

Professor Chappell had developed an excellent piece of software that did exactly what he set out to make it do: the C++ tool, FABBER, processes functional magnetic resonance imaging (fMRI) to recognise blood flow patterns in the brain and measure brain activity. It works well for the research group that Chappell currently leads, QuBIc, and many other developers in the field are also keen to create their own analysis models to work with it, but that’s where things begin to become problematic for Chappell.

Relearning Fortran through the medium of Star Wars

By Leanne Mary Wake, 2014 Fellow and Anniversary Research Fellow, Department of Geography, University of Northumbria.

The instructor heartened me when he kicked off the Introduction to F95 workshop, which took place at the Culham Centre for Fusion Energy on August 18th-19th, by saying "we want software engineers, not hackers." Science has reached a point where we produce and manipulate ever larger datasets, yet amongst the short-of-time and short-of-patience there is a temptation to produce code more with survival than sophistication in mind. This comes down to a clash between code that works versus code that works again, which is part of the Software Sustainability Institute’s mission and something which I will bring into my teaching from now on.

Immediately, I reflected on some of the less-then-useful code I had written in the past, along with my own learning experience as an undergraduate. Words such as ALLOCATION, SUBROUTINES, MODULES and FUNCTIONS, the latter, which has never been a characteristic of my writing, were mostly absent from my training as an undergraduate. Here are some others - PORTABILITY and GENERALISATION. These are not commands, but two virtues of a code produced by a software engineer as opposed to a hacker. Before I proceed, I make no apologies for using metaphors from Star Wars - it was on my mind at the time of writing - to highlight some of the learning outcomes of the workshop that I intend to use as pillars of my own teaching material and which, funnily enough, align themselves with the sustainability mantra.