Most scientific software projects started as a quick hack on somebody's laptop, but before you know it there might be dozens of future students and postdocs involved. However, unlike 30 years ago, today few of us are only one supercomputer from a single vendor providing a single compiler. Many modern scientific codes use multiple languages and scipt languages, they might use accelerated hardware-specific code (or even GPU support), they can rely on a whole set of external libraries, and with multiple people involved it rapidly gets almost impossible to track versions and bugs without professional software engineering tools. In fact, the latter is frequently true even for the smallest projects: How many times have you forgotten what directory contained the "fixed" version of your code, have you ever had to correct the same bug twice, or have you ever been hit by a bug in a compiler? In this talk I will not focus on science, but describe the software engineering aspect of a large open source project, including modern tools for version control, archiving developer discussions and bug reports, accepting public patch submissions, code review and quality assurance, and not least fully automated continuous integration testing. You might not need all of these for your first project, but they can potentially save you a whole lot of time and grief even when starting out in HPC!
Erik Lindahl completed undergraduate studies in engineering physics at Lund University, after which he received a PhD in theoretical biophysics at the KTH Royal Institute of Technology in Stockholm in 2001. He has performed research at Groningen University, Stanford University and the Pasteur Institute after which he assumed a position as assistant and later associate professor at Stockholm University in 2004. Since 2010 he holds dual appointments as professor of theoretical biophysics at KTH and professor of computational structural biology at Stockholm University. Since 2011 he is a member of the Swedish Young Academy.
Apart from research on membrane proteins and Gromacs development, I simply cannot help hacking assembly code on new architectures :-)
Cite this work
Researchers should cite this work as follows:
Eisner-Lubin Room 401, New York University, New York, NY
University of Illinois at Urbana-Champaign