Skip to main content

Software and research: the Institute's Blog

Latest version published on 6 October, 2016.

Epigonion.jpgAn Ancient Greek harp, which had been lost to the world, turns out to a fantastic argument for software sustainability.

At a conference last week, I talked to Domenico Vicinanza about the Epigonion: a kind of harp that was popular in Greece around the first century. None of the instruments have survived to the present day, so its existence was only known from historical records (such as the image shown on this page). It’s not just the instrument that has been lost, so have the skills and know-how needed to create one. This led Domenico’s team to set about a digital resurrection.

You can predict the sound an instrument will make if you know its characteristics: its size, shape and the materials used to create it. It’s far from easy to create this kind of model, and the result was so complex that it would take a standard desktop about 4 hours to reproduce a 30 second sample. Fortunately, Domenico works for GEANT who, together with the National Research and Education Networks, provide the network that links together European universities. Domenico’s team reproduced the sound of the Epigonion using grid computing, which harnessed the processing power of hundreds of computers across Europe.

Thanks to this work, and help from Astra project and the Lost Sounds Orchestra, the Epigonion can be heard for the first time in almost 2000 years (for example,…

Continue Reading

Latest version published on 6 October, 2016.

CoderDeveloper_1.jpgAsk a hundred people what the cloud is and you’ll get a hundred different replies.

Ask a hundred different people what a computer programmer does and what, if any, the difference is between a programmer and a software developer, and you’ll also get a hundred different replies.

Ask me what the difference is, and this is what I’d reply…

I divide people who write programs into three groups:


Anyone who can write some code that compiles and runs, which will do something they want when its given the right inputs. This could be a program, a script, some classes or a library. But, is it robust enough to handle inputs unanticipated by the coder? Is it the most efficient code possible? Can anyone else can compile and run it, understand how it works to improve, extend or fix it? Will the coder, six months from now, still be able to understand it or even know where to find it? Alas, all these are unknowns.


A programmer writes code (well, duh!), and also knows how to structure the code so that it is modular, robust and efficient.

A programmer is a coder with good habits. Programmers know how to write tests to ensure the correctness of the code, and value these tests because they make life easier when it comes to fixing bugs or making enhancements. Programmers know about version control and use it as an essential tool in their arsenal, which allows them to explore…

Continue Reading

Latest version published on 30 September, 2016.

You may recall back in February I talked about the importance of data formats when choosing a programming language for sustainable development.  Since then, I’ve received the following question…

“We’re currently putting together a machine for data intensive research. The machine will have a data-staging node, and 120 other nodes (configured using ROCKS) which each have several large local disks (>6TB/node).  We want to try out different ways of staging the data to the different nodes, and keep a record of what we’ve done.  The main things we’d like to record are: the number and size of files, the pattern (one to many, many to many, etc), and the locations to which the data are sent.

We’d like to use some kind of standard way of specifying how we want the data to move, and allow for different data transfer implementations to be plugged in behind this.  I’ve heard that OGSA-DMI might be able to help us here. Do you think that could be helpful?  Do you have any other suggestions or advice as to how we could provide a standard…

Continue Reading

Latest version published on 6 October, 2016.

EGILogo.pngThe EGI is an abbreviation-heavy community.

There's the EGI - European Grid Infrastructure - which provides researchers with access to computing resources. There's also the EMI - the European Middleware Initiative (see my post from yesterday). It's completely different to the EGI, and is working to unify the different middlewares used in Europe (middleware is the software that ties together different computer resources.) Oh, and let’s not forget IGE (not EGI or EMI). It’s the Initiative for Globus in Europe, which coordinates European work on Globus (another middleware). And I’ve not even got started on the SLAs, MoUs and OLAs - terms which abound like rabbits in spring.

Maybe the next thing the EGI should work on is an online glossary?

Latest version published on 6 October, 2016.

EGILogo.pngThis week, I'm at the EGI (European Grid Infrastructure) User Forum in Vilnius (if you want to know more about the EGI, see my earlier post).

Before the first plenary was over, the term sustainability had featured at least a dozen times. This is heartening news for the Software Sustainability Institute! I was particularly interested in Alberto Di Meglio’s plenary talk about ‘open-source middleware and the road to sustainability’ (middleware is the software that ties together different computer resources). Alberto is the leader of the European Middleware Initiative (EMI) and in his talk he identified three ways to aid the sustainability of their software: expansion of the user base, reducing costs and involving commercial partners.

Expand your user base

The more users you have signed up, the more important your software will be to the research community, and the less likely that it will be allowed to fail. But growing a community is difficult. You’ve got to be doing the right thing, and talking to the right people. As for doing the right thing Alberto raised a good point: if your current users aren't happy, you’re unlikely to please new ones.

Alberto’s team ran a survey to find out what their current users thought of the EMI’s software. They did well on the 'perception of usefulness', since people thought that their software was important to…

Continue Reading