Special Pleading Continues
Professor Easterbrook continues the special pleading for exemption that is so common among software developers that have not yet properly addressed important IV&V and SQA issues. This latest version of Professor’s pleading includes the following aspects; (1) a Red Herring, (2) broad generalizations, and (3) appeal to authority.
Appeal to Authority ( His Own )
Professor Easterbrook has not yet cited any of the literature associated with IV&V and SQA for engineering and scientific software. Literature that has presented procedures and processes that have been widely accepted and proven successful. What more can you say about that? Self reference based on a position of authority always fails.
Red Herring
Professor Easterbrook is the only person who has suggested that IV&V and SQA procedures and processes that are applied to commercial software be applied to engineering and scientific software. The subject software is not generally developed fresh from scratch but instead has evolved over decades of time. The engineering community has developed procedures and processes that take into account this obvious and critically important aspect of real-world complex software. Easterbrook attempts to introduce a comparison of apples and zebras into the discussions.
Broad Generalizations
The activities Easterbrook describes are Standard Operating Procedures for every software project that I have experience with. Direct experience. It is not IV&V Lite; it’s plain and simple SOP. SOP is not IV&V and SQA; never has been, will never be.
Collaborative comparisons of software results, and more importantly collaborative comparisons with experimental data, have a very long history in engineering and science software. This software is almost always not commercial software. In my industry, this work started in the mid-1970s. In turbulence modeling the work started in the early 1980s with the (in)famous Stanford Olympics. Infamous because so many calculations got so many different wrong results by so many different ways, sometimes when using the same software; the same models, methods and software. Turbulence is a hard problem.
It is common in many industries for user groups to be formed around a single piece of software. These groups have members that number in the 10s to a few 100s. Importantly the groups focus on a single version of the software, the frozen production-grade version of the code. That’s a lot of eyes looking in detail into all aspects of a single piece of software. From how I understand Easterbrook, the same kind of effort in the GCM community is significantly diluted relative to this standard.
A Prediction
I predict that papers will be written by Professor Easterbrook, reviewed by friendly cohorts who are equally unaware of the literature which has presented the modern methods that are applicable to engineering and science software, published in only the proper peer-reviewed Scientific Journals, and be quoted in the next IPCC reports that the Climate Science GCM software is pure. However, as mentioned above, self reference based solely on a position of authority always fails.
Not Even Wrong
This Comment by John Mashey is simply wrong. Look around this site, and this one, and this one, and this one, and this one, and this one.
Looks like we’re getting some Traction
This is interesting; Computational science: …Error. From Nature News, even. Comments allowed over there.
More on ODEs, MMS and Ill-Posed IVPs
First for the nomenclature: ODEs means Ordinary Differential Equations, MMS means the Method of Manufactured Solutions, and IVPs means Initial Value Problems.
This previous post provided some information on these subjects. So far as I know, that post presented the first results for application of MMS to ill-posed IVPs. That post suggested that for the numerical solution methods used therein, the original Lorenz system of 1963 has yet to be correctly solved.
I have some additional results, a summary of which is:
I think the Lorenz system has not yet been accurately integrated by any numerical solution methods. Higher-order methods plus, at the same time, higher precision representation of numbers will give results that might appear to be solutions. But, calculations for sufficiently long time spans will show that errors always increase.
I’ve uploaded a file here.
Internal Variability=Weather and Numerical Artifacts
This post is based on some notes related to verification and numerical artifacts that I made back in early July.
Read more »
V&V and SQA: Part 3, Verification
Verification Activities
The focus of verification is the actual coding of the software with objectives to determine: (1) that the coding corresponds to the equations given in the specification document, (2) the order of accuracy of the numerical methods, and (3) the order of convergence of the numerical methods. In general, the latter two objectives are purely mathematical and go to the heart of the coding of the solution methods. Several of the procedures that are used to pursue these objectives are given in the following discussions.
Read more »
V&V and SQA: Part 5, SQA
Software Quality Assurance Procedures
Read more »
V&V and SQA: Part 2, Requirements for Production-Grade Software
The requirements for release of software for production-grade applications include:
Read more »
V&V and SQA: Part 1, Definitions and Characterization
I’m going to post a series of short summaries of some of the central aspects of verification, validation ( V&V ) and software quality assurance ( SQA ) for production-grade computer software. These subjects have received significant investigations starting in the 1980s ( more or less ) and have reached maturation and have been successfully applied to a wide range of scientific and engineering software. I don’t intend to give a complete exposition of the subjects, the field is much too big.
Read more »
