Software and research: the Institute's Blog

By Mark Woodbridge, software developer, Bioinformatics Support Service, Imperial College London.

This is the first article in a new series called a day in the software life. In this series, we will be asking researchers from all disciplines to discuss the tools that make their research possible.

I'm a research software engineer developing tools to help life scientists organise, analyse and share their data. This is a varied and rewarding role but with its challenges - not least keeping up to date with both technology and the relevant research whilst trying to build robust, usable, self-sustaining software and getting credit for doing so. However, one thing that makes it enjoyable is being part of a wider development community. The innumerable open source software projects that enable or accelerate development of the tools that we build for others are an invaluable resource and were the basis of a recent discussion at Collaborations Workshop 2013.

By Mike Jackson.

Deciding upon a computing infrastructure for your project can be a daunting task. Do you want to use your institution’s existing infrastructure, buy a new one, or go for a third-party? Would an in-house cluster be best or a commercial cloud platform? Regardless of whether you seek a cluster, grid, cloud, HPC facility or volunteer computing infrastructure, there are a number of things you should consider.

Here are our top tips for choosing a computing infrastructure…

By Mario Antonioletti.

A version of this post originally appeared on the EPCC blog.

I participated as an instructor in a Software Carpentry bootcamp that took place this week in Oxford. The bootcamp was organised by Jonathan Cooper and targeted at researchers involved in the Oxford Doctoral Training Centre. Shoaib Sufi from the Institute was the other instructor at this event. The three of us taught about 30 attendees from various disciplines studying for DPhils (this being Oxford) as well as some Postdocs, giving them some basic computing skills that we hope will make their research more productive.

By Alice Tobin, science writer.

Combining the skills of a scientific researcher and a software developer, the research software engineer is ideally placed to bring scientific software up to scratch. An ongoing discussion that began at the Collaborations Workshop 2012 asks what obstacles need to be removed to clear the way.

Beneath the arched ceilings and elaborate chandeliers of Queen’s College, at the University of Oxford, an odd mix of researchers and software developers congregated last March. The 2012 Collaborations Workshop, organised by the Software Sustainability Institute (the Institute), brought together people from all sorts of backgrounds to discuss the future of scientific software development. And it was here, under the gaze of beautifully robed portraits, that they began to map out a new career path in the difficult terrain of academia.

By Mike Jackson.

The first encounter a user often has with your software is when they download it as a package. The nature of this package, and what the users have to do with it, can make the difference between a happy user using your software for their work, and a frustrated user, who has wasted a morning, and is now looking elsewhere.

Here are our top tips for packaging software…

1. If you can, distribute a binary

If you can distribute a binary executable, your users will thank you. This might be an EXE file for Windows, or an executable JAR file, for example. But, if all a user has to do is double-click on a file or run one or two commands - whether that be a “yum install”, “easy_install” or “java -jar application.jar” - to install or run your software, then they’ll be off and running far more rapidly than if they first have to try to build it.

By Kayla Iacovino, University of Cambridge

Remember research before computers? I sure don’t. But I’m told that back then, people still used slides to give talks. Figures were hand drawn, and references were found after hours upon hours in a brick and mortar library going through stacks of paper journals.

These days, we’ve automated a lot of the more mundane tasks involved in doing science. As someone doing their PhD in 2013, I’ve never had it any other way.

Even among us geologists, where one might suspect the research techniques to be as old as the dirt we study, science moves at a high-tech pace. One of the common tools used to analyse rocks is a type of vibrational spectroscopy known as Fourier Transform Infrared (FTIR* - essentially, this is an infrared light shined through a sample that
interacts with the molecules in its path in a specific way). The spectra of light that comes out the other end can then be analysed to get at information about the sample’s chemical makeup.

By Jane Charlesworth, University of Oxford.

I am a biologist. I also love computers. Sadly, I have many colleages who find programming scary, and I used to be one of those people. Here is how I learned to stop worrying and embrace programming as a tool for my research.

All the tech skills are self-taught, or picked up from eavesdropping on computer scientist friends in the pub. Most of my colleagues are either in the same boat or reluctant to spend their research time learning to write reproducible code. Even those of us who are eager to learn don't know where to begin. I think this represents a crisis in biology education.

I did a degree at a top UK university about ten years ago. A good 95% of my degree consisted of training for working in a wet-lab, doing molecular biology. I have never worked in a wet-lab. Granted, when I did my degree, the first human genome was still unpublished, but I find it impossible to believe that our course organisers could not have foreseen that sequencing was a rapidly maturing technology and the students they were training would need to be equipped with the skills to deal with the resulting deluge of data. 

By Luis Figueira, SoundSoftware

We are very excited to announce the first competition for SoundSoftware.ac.uk prizes for reproducibility in audio and music research. Our goal is to promote the development and release of sustainable and reusable software and datasets alongside published research.

In a few of our recent papers and presentations we've seen that much audio and music research work is published without the accompanying software implementations. One reason is a lack of self-confidence - the fear that one's code is not good enough to share. (You can read more about this in our ICASSP 2012 paper, Towards Software Reuse in Audio and Music Research and in the Institute's post Haters Gonna Hate - why you shouldn't be ashamed of releasing your code). We believe that one way of countering this fear is to promote the idea that sharing is a worthwhile goal in itself.

By Stephan Lautenschlager, Fellow and PhD Candidate at the University of Bristol

Palaeontology, the study of fossils and extinct organisms, has a reputation for being a very traditional and dusty discipline. Partly influenced by Palaeontologists’ portrayal in the media, the public imagines them roaming the badlands in the search for new fossils. Alternatively, they are seen as ivory tower scientists, spending most of their time in museum collections studying the bones of long extinct animals. Although both images hold a partial truth, palaeontology has experienced a tremendous paradigm shift in the last decade and has evolved into a multi-disciplinary science. Advances in hardware and software, and their wide and comparably inexpensive availability have led to a surge of computational methods to study fossils.

By Alexander Hay.

What is the best open-source software? This is a question I decided to answer, and so began a long and no doubt eventful journey of discovery. One of my first destinations was at an open-source break out session, which took place last month at the Collaborations Workshop 2013. Cue much debate.

It's not possible (and probably not helpful) to decide on the best software overall, so instead I have focussed on open-source software that is exemplary in certain areas. Here follows the first three examples of this software and why we chose them. In future posts, I will work through the other examples on our list.