Software and research: the Institute's Blog

By Aleksandra Pawlik.

Every six months we meet with our Fellows to discuss their experiences of Fellowship programme. Last week's Fellows' meeting had a very busy schedule! Almost 24 intensive hours (with a break for a good night sleep) filled with discussions, ideas and experiences.

By Arno Proeme.

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

Unfortunately, the APES project (pronounced A-PES) has nothing to do with our chimp cousins, and instead stands for Advanced Potential Energy Surfaces. It will help researchers advance their understanding of the structure and function of molecules by improving the models used to represent their force fields. For example, it could help understand the interaction between the simian olfactory receptors and isoamyl acetate, which gives bananas their irresistible allure.

By Allen Pope, postdocoral student and Fellow.

With sponsorship from the Software Sustainability Institute, the UK Polar Network (UKPN) are running a Software & Polar Research Workshop at the Scott Polar Research Institute, Cambridge on Tuesday 17 September 2013. The workshop is currently in the planning process, but please save the date in your diaries and check back regularly for updates!

Where

Scott Polar Research Institute, University of Cambridge, Lensfield Road, Cambridge, CB2 1ER.

By Mike Jackson.

Last week saw the first Software Carpentry boot camp to be held at the University of Southampton. Organised by our fellow, Robin Wilson, fifty researchers from the Institute for Complex Systems Simulation and Computational Modelling Group, attended this boot camp, with Nelle Varoquax and James Morrison (who attended our Manchester boot camp back in April) as instructors.

Institute staff Steve Crouch and Tim Parkinson provided local help. Pop over to the Software Carpentry blog to read about how the boot camp went, and check out Six useful things I have learnt at Software Carpentry boot camp written by a satisfied attendee.

By Craig Haiss, HelpScribe.

If you want people to use your research software, it needs good documentation. Many people employ the help of a technical writer to write documentation, but how do you get the best out of this relationship? We turned to Craig Haiss for help. He set up HelpScribe to share his ideas with the technical writing community, and in 2010 it was named one of the most influential technical writing blogs on the web.

1. Accept that no tool or process is as simple as it seems

The more functionality a tool provides, the greater the chances a user will become confused by features of that tool. Even the iPhone, with it's simple touch screen interface, has a 150+ page manual.

Do not assume that your research software or process is so simple that minimal or no documentation is sufficient. Doing so could cost you both time and money when research grinds to a halt due to unanswered questions or misunderstandings.

By Aleksandra Pawlik.

This May, Software Carpentry once again went European with Jagiellonian University hosting the first bootcamp in Poland. There were 28 attendees: most of them postgraduate students and a few faculty members. They represented a range of disciplines from mathematics and theoretical physics to biology, genetics and medicine. 

By Simon Hettrick.

Intellectual Property (IP) is a thorny issue in academia, generally because people don't know who owns what. There's a lot of hearsay, rumour and - frankly - misunderstanding about IP ownership, so we've decided to run an experiment. And we're going to need some guinea pigs...

The provisions that govern IP ownership appear fairly straightforward. Your IP is your own unless you work in a role where you're expected to generate IP, in which case your employer owns it.

Things get more complicated, when people start to ask "Are PhD students employees?" and "Do I own the software if I wrote it on my work computer, but outside of working hours?". Add to this employment contracts that deal with the assignment of IP, even though these often go unsigned and some contain clauses that are not legal. And, of course, the fact that who owns what is often not discussed... right up until someone creates something valuable and tries to make money from it.

By Mike Jackson.

A couple of years ago I was involved in a project for which we needed an ontology. I was very uneasy as prior experience, over the years, had taught me that ontology meant meetings that overran and the same discussions, with no outcomes, over and over, a conceptual Groundhog Day. But my worst fears were, thankfully, not realised…

The project I was involved in, SPQR, was concerned with epigraphy, information about inscriptions – such as grave markers, tablets, signs or graffiti – from the ancient world. Epigraphic data is often fuzzy and incomplete due to uncertainty over where and when inscriptions originate and to who they refer. SPQR’s goal was to see whether using linked data to represent epigraphic data and join multiple data sets together offered a means by which the combined data could be more readily explored and browsed than relational or XML representations traditionally used.

By Mike Jackson.

You have access to a new computing infrastructure – a cluster, grid, cloud, HPC facility or volunteer computing infrastructure – and you wish to get your application running on it. This may be as simple as copying across an executable and running it, or, it may equally require a significant re-working of your application’s configuration or code. How you proceed depends upon your preferred working practices – you may want to scope out the work in advance in some detail or you may just want to get on and experiment.

How you port your application depends upon your application, your infrastructure and your personal preferences. However, there are a number of things that have the potential to make the porting go smoothly and that will also help others who wish to undertake similar work in the future. Here are our top tips for porting your application…

By Randall J. LeVeque, professor in the Department of Applied Mathematics at the University of Washington in Seattle.

This post was originally published as a news item on the Society of Industrial and Applied Mathematics website (SIAM News, Vol. 46, April 2013).

There is no... mathematician so expert in his science, as to place entire confidence in any truth immediately upon his discovery of it... Every time he runs over his proofs, his confidence encreases; but still more by the approbation of his friends; and is raised to its utmost perfection by the universal assent and applauses of the learned world.

---David Hume, 1739*

I am an advocate of sharing the computer code used to produce tables or figures appearing in mathematical and scientific publications, particularly when the results produced by the code are an integral part of the research being presented. I'm not alone, and in fact the number of people thinking this way seems to be rapidly increasing, see for example [1–3, 6–8, 10].