In this month’s installment of Andrew Jones’ ZDNet series on high performance computing, he discusses a subject near and dear to my heart: scientific code development. Given that I’m a classically educated software engineer, I have a somewhat myopic view of code development for scientific computing [et.al, HPC]. Requirements gathering, numerical analysis, code development, rigorous testing and constant evaluation have become a normal part of my life.
Enter Dr. Reg Ular Scientist. Dr. Scientist takes a different approach. Does it function and produce reasonable results? Done. I realize I’m stereotyping in the worst of ways, but we’ve all seen this happen. Scientists are, by nature, not software architects. They’re domain specialists.
By implication, this state of affairs might be responsible for much of what some people see as the mess we are in with respect to assurance of results from the models and portable performance of the codes. The same argument might also be extended to engineering packages and data modelling.
Now that we’ve identified the obvious, how do we strive for better scientific software? Step one, education. Educate the scientific masses in the same way that they were originally instructed in their respective discipline. HPC resources are scientific tools that require careful manipulation and, in many cases, calibration.
Any reputable physical experiment would ensure the instruments are appropriate to the job and have been tested. They would be checked for known error behaviour in the parameter regions of study, and chosen for their ability to give a satisfactory result within a useful timeframe and budget. Those same principles should apply to a software model.
And, of course, collaboration is helpful.
The trick then must be to ensure the scientist code developer understands the methods of numerical software engineering, as well as its issues. Software engineers on the team must equally understand that the code is just part of the science, and not usually a goal in its own right.
As always, Andrew’s article hits the spot. This is a subject that I face on daily basis. Ideally, we need to avoid a situation where scientists are forced to become code wizards and conversely, software gurus are forced to become code janitors. Take a read of Andrew’s latest article here.