Implicit Function Theory Applications; Part 1: Method of Exact Solutions
In a previous post I gave some background info about implicit function theory and how it might be useful. In these notes I have used results from applications to the equation of state to develop a few exact solutions for extremely simple transient, compressible flows that include fluid-structure interaction. These notes address the case of mechanical coupling of the fluid to a deformable / flexible wall. I have also included an introduction to the case of coupling of fluid systems through a common deformable / flexible wall. Additional notes will address the case of thermal interactions for both a single fluid system and coupled systems.
I kind of ran out of steam when I got to coupled-systems part of the present notes. There’s a lot of ground to cover for this case and I’m thinking a separate report might be the way to go. With coupled systems you get more that just twice as many things to look at compared to the single-system case.
I think these solutions might be candidates for analytical, and numerical-benchmark-grade, Method of Exact Solutions ( MES ) for verification of limited aspects of coding of transient compressible fluid flow model equation systems and solution methods.
I have uploaded a file.
Consider these notes as a rough draft of a report and let me know what you think about all aspects.
More on V&V and SQA at LANL for ASC and the NNSA
This previous post mentioned V&V and SQA at Los Alamos National Laboratory ( LANL ) within the framework of the Advanced Simulation & Computing ( ASC ) Program for the National Nuclear Security Administration ( NNSA )
Verification and Validation of scientific and engineering software seems to have become a very important part of scientific and engineering software at Los Alamos National Laboratory.
This section:
Typical Questions That V&V Can Answer…
Has this entry:
• “Models can be validated without data.”
Wrong! There is no validation without data because model validation must assess prediction accuracy relative to a physical reality. While code verification and calculation verification are concerned with the accuracy of the numerical implementation and convergence, respectively, validation activities focus on the adequacy of numerical simulations when applied to the description of reality, which requires experimental observations. We nevertheless recognize that the lack of test data can pose serious problems to model validation. Rigorously controlled expert elicitation techniques can provide information that is substituted to experimental testing in cases of severe lack of data and uncertainty.
Code-to-code comparisons are not Validation. Never have been, never will be.
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.
Continue reading
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.
Continue reading
V&V and SQA: Part 5, SQA
Software Quality Assurance Procedures
Continue reading
V&V and SQA: Part 2, Requirements for Production-Grade Software
The requirements for release of software for production-grade applications include:
Continue reading
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.
Continue reading
Models Methods Software 