Computational Science And Engineering Software Sustainability And Productivity (CSESSP) Challenges

Is writing code essential for your every-day work, be it research, development, or engineering? Did you have to take a coding shortcut here or there to get the task done? Do you think that your code would need a bit more polishing before handing it out to other people? If you answer all these questions with yes, you're not alone!

Complexity of CSE Software

While coding can be a joy per se, for computational science and engineering (CSE) it is typically a vehicle to answer a higher-level question. How to redesign a transistor to make it more durable? How can to reduce the drag of an airfoil? How to better predict the weather? These are all incremental processes, where new insight is typically obtained through the consideration of ever more complex physical processes. As more complex models are incorporated, your code needs to be able to adapt.

'Adaption' for CSE software often results in a complete rewrite. The new code will then be designed to deal with the more complicated setup—but not more than that, since you might need to get the paper published. [Skipping rant about questionable incentives in research here] The problem with such a 'good enough' approach is, that your code is unlikely to be reusable for others with slightly different requirements, and that you probably have to rewrite the code for the next-generation model. In the long run, you would be much better off by a broader and more flexible approach to engineering your code.

Raising Productivity in CSE Software

To deal with the issues outlined above, the Computational Science and Engineering Software Sustainability and Productivity (CSESSP) Challenges Workshop was held in October 2015, bringing together people from CSE as well as from software engineering. The workshop report is now available on the NITRD web page [direct link to PDF]. I participated in the workshop, so let me reiterate four of the main messages in my own words:

  • More education on basic tools is needed to boost CSE software productivity. For example, why is version control is still not widely adopted for CSE software? Proper education and training on writing software in a research context needs to be provided. The training provided by e.g. Software Carpentry needs to make it into curricula.
  • More CSE software needs to make it into production software. How should CSE research software be useful to the general public if it is only used by the person who wrote the code?
  • Communities and ecosystems are the foundation for a rich CSE software stack. We need to find ways to reward all interdependent parties rather than only the highest level integrator. For example: If your CSE software relies on other libraries (solvers, threading, etc.), credit for the successful use of your software also needs to be propagated to the people working on the other libraries you are using. Keep in mind that your credit is not diluted when being passed on to others!
  • CSE software provides new stimuli for software engineering research. Blindly adopting software engineering practices to CSE software has yielded bad results in the past. In particular, fine-grained abstractions can ruin performance (e.g. many virtual calls to access a single number); it has been reported that some projects have discarded any type of abstraction in an act of overreaction. There is ample of room for interesting research on software engineering under these performance constraints.

Overall, I consider the workshop report important for future directions of CSE research. Most importantly, the report raises awareness about CSE software being a significant effort which requires resources beyond the typical timespan of a three-year research project. As such, CSE software needs long-term infrastructure; and funding infrastructure is scarce.

This blog post is for calendar week 18 of my weekly blogging series for 2016.