A large portion of the supercomputing code driving scientific research and engineering design is written by scientists who are not software professionals. NAG’s Andrew Jones writes that too much of our scientific code base lacks solid numerical software engineering foundations.
Someone remarked to me recently that the problem with scientific software is that most of it is written by amateurs. Harsh perhaps, but it got me thinking. The point behind the remark is that most of the software used for simulation in scientific research, especially on supercomputers, is written by scientists rather than by professional numerical software engineers. 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 modeling.
Jones goes on to say that because our scientific code base lacks solid numerical software engineering foundations, it potentially puts correctness and performance at risk when major renovation or parallelization of the code is required. Read the Full Story.
This ZDNet article [http://www.zdnet.co.uk/news/it-strategy/2010/01/28/are-we-taking-supercomputing-code-seriously-40004192/] was originally written a year ago (and discussed at the time on InsideHPC [http://insidehpc.com/2010/01/31/andrews-corner-scientific-codes-and-their-creators/]).
The core point of the article is about finding the right balance of software engineering expertise in large scientific applications. Enough to trust the results but not over-engineered to swamp the science effort.
It is interesting that it has re-surfaced a year later, when activities such as the European Exascale Software Initiative (EESI [http://www.eesi-project.eu]) are exploring the same issues of finding the right software engineering balance in the quest for viable exascale software.
Thanks, Andrew. I did not know about the previous post. Your ZDNet story was sent to me this weekend by someone who urged me to write about it.
As you say, scientists are not multi-discipline and are not expected to write wonderful programs. Attempting to convert scientific formulas to sometimes complex language constructs is not easy and the scientist may have to reduce the formulas to more basic mathematical components. Very often they do not have the time to do that or write the program and sometimes an external person at a college, university or working at home is utilised, providing the person is approved to have knowledge of the project or the specific formulas at all. Regarding the numerical software engineering foundations, a compiler, VM or run-time system often have a selectable facility to activate a difference reducing method to negate a large part of the effect of the calc excess or variance compulsorily fitted to the computing device and this method of introducing increases in accuracy of results can be user selected in some versions. Where it is not built-in to the software it can be manually coded in to a program by the author using popular methods like R.E.C, R.X.E, PLITAR or NITARCAL and some can be obtained as a collection of libraries from a national institution or on the internet (details can be supplied). Some of the libraries and code providing conformance to IEEE-854 and 754 standards are getting out of date as new or alternative computer types have been introduced in past years and the institution, ministry or department may not have commissioned them to be ported over to some computers and enumerators. Accuracy of results and producing something that is acceptable to the persons having oversight of the project is paramount in being able to justify the continuing of a project and the necessary financing of it in order to satisfy the commissioning body.
We cannot afford to continue to allow amateurs to write computationally intensive scientific codes. They are part of the reason we are not getting to efficient terascale computing much less peta and exa.