“All the physical science in the world is simply garbage if not properly constructed and coded,.”

Not so, sir.

My engineering career spanned the period before computers were widely used, up to today. I can assure you that sound physics and engineering were performed by competent, real engineers, (in the fields of civil, mechanical, electrical, chemical, and others) without the use of coding into software and running on computers. If you doubt this, then I invite you to have a look at any building, bridge, dam, power plant, chemical plant or refinery with a cornerstone plaque or startup dated earlier than 1970.

Many times a computer simply adds more time to the task, and useless digits in insignificant places. We had (and still have) perfectly good methods for calculating and designing almost everything — and it was certainly not garbage, and certainly no coding was necessary.

The legal reality is that almost every large new software system is a failure, and results in lawsuits. While there are many reasons for this, the inability of software *engineers,* systems architects and analysts, code writers and debuggers, to deliver a working product on schedule is a major factor.

The knowledge that the software *engineers* are coming to deliver a new system causes business owners and others who contract for such systems to cringe. They know the system will fail, and lawsuits will result.

Just one (of thousands I could mention) is the computerized payroll system for the Los Angeles Unified School District in California, circa 2007. If they (the programmers) cannot do something as simple as add up hours worked, multiply by dollars per hour, perform some equally simple deductions, and print a paycheck, all that for a few thousand employees, how can they be expected to do something a bit more complicated like a climate model?

R S Bridges (19:48:32) :
…
So, Squidly, I salute you, and all of your brethern! Go forth, and prosper!

In large part I am in agreement with what you are saying. Conversely the same could be said software engineer to scientist. This, after all, is a cooperative effort. There should be no dictation flowing either direction. I find there is a clear and present contrast between a “programmer” and a “software engineer”, that is the crux of what I have been discussing. To some who have said “a software engineer is not an engineer” or that “there is no such thing as a software engineer”, they are quite naive to the development of software in general. Ultimately, the process of software development is simply the translation of human process to machine process. Of this, there are many facets involved, from the engineering aspects, to the coding aspects, and many branches in between. The trick to developing successful software is proper organization and translation, this is usually not simply a task for a “coder”, as “coders” don’t usually posses the skill set necessary to adequately architect the application structure itself with all components considered.

“That said, it is still the physical science that is the underlying basis for the models, not the code.”

I disagree with this. Again, it is a cooperative effort. One relies on the success of the other. All the physical science in the world is simply garbage if not properly constructed and coded. Conversely, the best software design and coding is worthless without proper physical science instruction. So, again, to be successful, one cannot live without the other. They need to be harmonious. These are not easy or trivial tasks, but properly set forth can be accomplished.

Ah ha! .. Very thoughtful comments! Nice!

I completely agree with you concerning language construct and organization of FORTRAN and what that brings to numerical formula processing. Your comments are certainly very valid. I would content however, and especially when considering the enormous budgets employed, one could utilize a more modernized language (preferably a fully compiled language that produces binary code for performance optimization, ie: this would exclude Java) and provide even more robust scripting mechanisms that would allow the use of heavy mathematics in robust expressions that could then in turn be pre-compiled into the foundation language, optimized and compiled to binary codes native to the host machine. Such an approach as this will allow for the proper architectural abstractions, allow the software engineers to employ flexible and robust design concepts and patterns, allow software developers to write compartmental coding segments abstracted from adjacent logical modules, and probably most importantly, allow the “scientists” to develop robust mathematical representations of physical processes and complex interactions utilizing language, verbiage and structure that they are used to.

In this scenario, everybody wins, and result could be something that may actually stand a snowballs chance in hell of working. And even if it doesn’t work, you have developed something that can adapt as your learning and understanding culminates and expands.

IMHO…

George Tobin (09:01:16) : I was unaware that any blame had been directed at GISS software engineers. My understanding was that they were faithfully implementing the bogus sensitivity assumptions and all the rest of that which comprises current climate modeling ideology.

George, you are laboring under the assumptions that the code was written by a software engineer and that there was a division between the designer and the coder. The code looks to me like it is largely written by folks who learned programming as a sideline or “had a class in it” not by professional programmers. (Yes, anyone can learn to program just like anyone can learn to write poetry… that does not make you a professional programmer nor a good poet…)

I’ve read GIStemp front to rear. It looks like it was written by folks who had a FORTRAN class once, years ago (I would guess some of it was written by Hansen himself decades ago…) and do not make production product for a living. It also has “layers” that look like kludge added on top of kludge over time. Some blocks are ALL CAPS and look like F77 style (and syntax). Other newer chunks are mixed case and F90 style. In short, “it just growed” is how it looks. There are exceptions.

==

OK. No disagreements with the internals of the code. I will grant your (stated) expertise in the various languages, and the ability of a (good) programmer to write (good) code in virutally language. No problems.

But … What about the need for configuration control? Is there ANY change control, change testing, testing “debug” notes or corrections?

Is there any “lost” code that could/would/might produce arbitray trash if a single thing goes wrong? For example, if we put a real value of CO2 and a real value of temperature? Does it produce a valid “radiation in” as a check? Who made the changes? Does it process “real data” if the year or earlier CO2 results and temperatures change? (In other words, if you put in values for 400 ppm CO2 in 1980, does it produce a valid temperaure as it would if the year were 2050 and the CO2 were 400? If CO2 were changed to 200, does it produce real world temperatures for say the year 1800? )

Who tested each module, if the whole thing has not been tested? how do we know the actual calculations in the repeating module are correct? Who verified its input, and what are its input variables, and what are the “coded in” variables?

When a change or update was made, who made the change? Who authorized the change? Who tested the result after the change? What was the previous coding, and what was the changed coding? Has it been” hacked” or do the results have any chance of being “hacked”? Were results as printed actually teh results from a test run, or were they merely typed in afterwards?

If this ran an ATM machine, would you sell it to your bank? Would your congressman put his money into this program if it were a ttax processing software?

So, Squidly, I salute you, and all of your brethern! Go forth, and prosper!

Drawing on my experience as a chemical engineer, because the chemical systems I modeled were non-nuclear, I was bound by the laws of conservation of mass and energy. The models always checked to see it the number of pounds, kilograms, or tons of products equalled the same measure of reactants. If the mass balance did not close, the program printed a big warning.

Do climate models bother to calculate an energy balance? It would seem to me that if you got a bogus answer of 1 x 10^20 temperature in March 2016, then the answer is “No”.

If they don’t anergy balance, then how can you have ANY confidence in the results?

…the sheer magnitude and complexity of the system still defies attempts to fully understand all of the interactions, leading to small errors having an ever-growing cascade effect as one tries to predict further into the future.

Put more simply, imagine working on a very complex algebra problem. The issue is that you copied one little part of the problem wrong. In your first pass, simplifying, substituting, and performing other operations, that wrong bit interacts with another element of the problem, the result of which is corrupt. Each subsequent pass through the problem causes the erroneous segment to corrupt more of the total problem as it is combined with other elements, and, by the end, your final answer is utterly wrong. This is very much what inhibits long-term forecasting on even a local scale and short time spans. Taking this up to the global scale allows vastly more chances for error, and projection years into the future gives any errors much more time to cascade to the point of rendering the entire model useless. The calculations may be perfect, but a faulty starting point ruins the entire process. Unfortunately, this isn’t the greatest difficulty. Back to the hypothetical problem, imagine that you don’t even get copies of any of the formulae you need, nor even the base problem. Instead, all you have are the base values to use and thousands, millions of answers, each coming from different base values (you don’t get told what any of them are), from which to figure out the starting equation. It gets worse. Some of those answers are wrong, and you don’t know which ones. It gets worse still. The answers are divided up into hundreds of groups, each group containing answers to certain combinations of formulae and base values, and you aren’t told what formulae or values are used or how they are combined. Nope, not done getting worse, yet. In fact, you are told that none of the groups contain answers to the actual problem you need to solve. Instead, example answers for the overall problem are supposed to be composites, somewhat like the mean, of all of one answer (the tenth, for example) from each group, but you also have to figure out how those subordinate answers get combined into the big one. In the end, you have mountains of data, an unknown amount of which is faulty, from which to determine all of the formulae, how the formulae are used to produce the subordinate answers, and how those are combined to get the main answer before you can even start working on the problem with the given starting values. Guess what? This isn’t even accounting for time lapse yet.

Someone may read that last paragraph and think, “Models on the global scale don’t have to be that precise, though; they can be more general and still get the broad picture.” Well, let’s run with the picture metaphor, shall we? I would roughly equate simplifying components of a model to reducing the number of pixels in an image. Sure, you can do it, but you loose definition. Do it with a complex, intricate picture, and you will very quickly end up with an image people misinterpret, or one from which it is impossible to discern anything at all. Sure, you can dumb down the models by making them less complex with estimations of values instead of solid formulae, but you have to admit that doing so destroys the accuracy of that broad picture. A more direct example comes from graphing a curve to fit plotted points. Reducing complexity could be seen as using fewer data points from which to extrapolate a curve. The problem with this is that, as the data points are made fewer (thereby spreading out on the graph), you may end up missing movement in the actual curve occurring between points and graphing a curve that is completely wrong. When it comes to scientific (quasi-scientific in this case, really, but that’s a topic for another day) analysis of data, generalization is bad, and detail is good.

However programs like modelE are implementations of some deep domain knowledge, and the trickiest thing is the application of that domain knowledge rather than the coding itself. Ie problems are more likely to arise because of a physics error than a coding error.

I have been programming all my life, C++, C#, COBOL too, so this FORTRAN stuff doesn’t look too alien to me. However I can’t make head or tail of the modelE code, not because I can’t follow the flow of the code, but because I don’t understand the domain knowledge (climate physics) behind it.

Somewhere in the code I saw that it assumes 360 days in a year, or 12 equal months of 30 days. Not a bad assumption if you are forecasting over a short range of time. But when you are trying to predict global temperatures 100 years into the future – that is a very different story.

This really would be the End of the World – you’ve got a loop there somewhere…. ;-)

.

cheers David

Gary was trying to defend what he does for a living. Why, I’m not sure. He calls himself a ‘software engineer’ but is not necessarily any more an ‘engineer’ than a ‘building maintenance engineer’. His ‘admission’ is at about the same level as that of a building maintenance engineer’s admission to the sad state of architectural design. Ho hum.

Should the climate models be used for trillion dollar decisions? Of course not! But for far better reasons than crappy, hard to follow code. Let’s focus on the real issues instead of peripheral ad homs like ‘crappy code’.

Move along people. There’s nothing to see here.

So if it ain’t broke… Everything’s hunky dory. What temperature do you want? What sea level rise do you want? Etc, etc…