Software development

This week we said goodbye to our Summer of HPC students Anna, Marta and Tomislav.

These students from around Europe have spent the last 7 weeks with us at EPCC immersed in HPC, and each working on a specific project in the field. This is a great because not only do they gain experience and interest in HPC but we also get a useful, tangible, outcome from these projects.

With my Software Sustainability Institute hat on, I recently participated in a back-to-back Data Carpentry and Software Carpentry course sponsored by the University's Research Data Service here at the University of Edinburgh. The courses were held in the main University library in a gorgeous room with a glass wall, providing a rather distracting view of the Meadows parkland. 

Applications are now open for the Software Sustainability Institute’s 2017 Fellowship programme. Apply at bit.ly/fellowship-programme by 2nd October 2016.

This guest post by Simon Hettrick, Deputy Director of the Software Sustainability Institute, explains how the role of research software engineer has gained greater definition and recognition.

On a beautifully sunny day in March 2012, a small group met at Queen’s College Oxford and challenged a long-standing problem: why is there no career for software developers in academia? They didn’t know it at the time, but this meeting led to a nationwide campaign that created a vibrant and rapidly growing community, and established a new role in research: the Research Software Engineer.

Summer of HPC visitor Tomislav Subic gives a summary of his project at EPCC: a visualisation of the UK Met Office's weather model.

A legend says that there was once a warm sunny day in Scotland. I have started my quest to find out if the myth was true, but I was not the only one.

Over the last 10 years, the growth in performance of HPC systems has come largely from increasing core counts, which poses a question of application developers and users – how to best make use of the parallelism on offer?

Choice, choice, choice

I'm often asked "What programming language should I learn for scientific computing?".  Or I get involved in religious-like discussions about the best programming language for a particular task, or of all time (think Python vs Fortran, Go vs C, etc...). What's my answer?

Just recently I realised that, to me, programming languages are like musical instruments.

Last week I attended an ExTASY tutorial here in Edinburgh. The project aims to build a set of Extensible Tools for Advanced Sampling and Analysis (hence the name) to allow chemists who use computational methods and off-the-shelf molecular dynamics (MD) packages (such as GROMACS, AMBER and NAMD) to be cleverer and more efficient with their simulations.

The Extasy-based tools are well worth considering if you are doing MD calculations. If you want to be smarter about how you do your simulations, take a look at ExTASY.

Useful software design

Prompted by a recent discussion of a blog post discussing applying commercial development techniques to academic software development, I've been trying to formalise the software design process I'd recommend to academic software developers.

Just the term, software design, puts a lot of people off. It sounds like a long, elaborate process, full of requirements capture and storyboards, but it really doesn't have to be. I think anyone who is writing programs will be doing some form of software design, even if that design is just following the process they've always used, but are just not formalising it. However, formalising your software design could bring important benefits.

Recently I seem to have had many conversations about programming languages for HPC. In some ways this is not a new subject - I have been having similar conversations for the last 20 years. However as HPC hardware evolves, machines become more complex and the issues that need to be addressed by programmers also become more complex. So it is not surprising that we are wondering if there is more the compiler could be doing to help us.