By Josef Weinbub, Institute for Microelectronics, Technische Universität Wien

This article is part of our series: 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.

We research software engineers live in great times. Granted, our work is not as valued as it should be and we struggle for funding. However, looking at the vast availability of free open source tools available today, we are in an excellent position to cut ourselves loose from the shackles of proprietary software. To provide you with some context: I use and develop free open-source tools in the field of semiconductor device and software simulation.

For this, my colleagues and I use deterministic approaches such as Finite Difference, Element and Volume schemes to discretise partial differential equations. We also employ stochastic approaches, such as Monte Carlo simulations. My work involves developing, releasing, contributing, maintaining, and interfacing tools to strengthen the free open-source movement in my field of research. So, what kind of software do I use? There are four categories of tools required: development tools, libraries, visualisation tools and paper writing tools.

Let's start with development tools. I primarily develop in C++ using my favourite Linux distribution Funtoo, with a package manager that allows for on-target building of source code. I also rely heavily on the GCC and clang compilers to build my applications and libraries. CMake eases the pain of supporting multiple build platforms, whereas CTest helps me keep my software stable by enabling automatic tests. I use the feature-rich Qt suite to develop user-interfaces and Valgrind to identify memory related errors. The repository system Git keeps the code base sensible, especially in a multi-user development environment.

From time to time, I use Python, because it's convenient (especially for a C++ guy like me). OpenMPI allows me to utilise an MPI whereas Paraver exposes me to the sometimes awful reality of doing so. Oh, and Boost.MPI eases the pain of implementing MPI code in the first place.

On now to libraries. I am a big fan of library-centric software design. Applications should merely interface with libraries, harnessing their functionality - ultimately giving them purpose. The Boost libraries enable access to a plethora of non-domain specific functionality, such as Boost.Fusion. The VTK library provides my applications with data structures and algorithms to visualise simulation results. Pugixml, as a header-only XML library with XPath support, enables the configuration of applications during run-time. Lua also provides such configuration abilities while in addition throwing in a neat way of evaluating mathematical string expressions to numerical values.

To solve systems of linear equations I use Trilinos, PETSc, and ViennaCL. Then there is deal.II and FEniCS, allowing me the questionable joy of performing the occasional finite element simulation.

I rely on several mesh generation tools, such as NETGEN, TetGen, Triangle, Gmsh, and CGAL. The latter also provides a vast set of geometry-related algorithms. METIS enables the partitioning of graphs and meshes for specific needs.

Now onto visualisation tools. After all, a big part of my research is not only to implement the research software but to visualise how it works. For plots, I use gnuplot or Rscript, depending on my mood. ParaView enables me to do sophisticated scalar or vector field visualisations.

Finally, and before I forget, there are the paper writing tools. As a researcher, I have to write all sorts of technical papers. I use LaTeX, while Open Office is occasionally summoned for some quick text processing. Inkscape and GIMP allow me to express myself in a graphical manner.

The bottom line is that the many tools I use for my research are all free, open-source software. So wouldn’t it be a wonderful world we research software developers could live in, if we could just get the required support from funding institutions to develop and maintain open-source tools? Software is often treated like a secondary concern, expected only to exist and be available without much consideration given to how it is created and maintained. For a change to happen, we need to aim high by inducing a change in mindset. It must be made clear to all that free, open-source software supports research in a far superior manner than any alternative – not to mention restrictive - proprietary solutions.