Fury Scarcely Suffices
h/t RtO
By and large, when it comes to climate, and the changing thereof, my ignorance is fairly prodigious. I know some physics and chemistry, and can sometimes discern statistics from cuisine. However, I must admit that my disinclination towards AGW is derived at least as much from temperamental and non-climate bases as from any knowledgeably reasoned conclusions about climatologists' consensus.
Since ClimateGate, though, I can add knowledge to reflex. While I bow to AOG in all computer matters, my ignorance here is not total: I have a graduate degree in computer science, and have spent a couple previous lives in the field putting daily bread on the table.
With regard to the programming that is, in effect, the climate of the future:
This is complete, unadulterated, distilled, thoroughgoing essence of nonsense. There is simply no charitable explanation that doesn't involve lavish accusations of ignorance or disingenuousness.
Most climate modeling is done in FORTRAN. Despite being one of the oldest high-level languages, it is still one of the most popular for numerically intensive applications. This largely due to its long term presence on mainframe computers; by mainframes' very nature, languages developed for them (see also COBOL) will be much more persistent than those developed since the advent of personal computers. (Update: per rchrd's comment, I should add that Fortran is still widely used because it is efficient, portable, and, perhaps most importantly, well understood. For demanding numerical applications, SFAIK, it is the gold standard. Corrections are underlined below.)
However, the FORTRAN versions used in most, if not all, climate models has some significant shortcomings.
Foremost among them is that, prior to FORTRAN 2003, it was a procedural language, as opposed to structured. FORTRAN allows code that is as difficult to follow as a bowl of spaghetti; modern structured languages essentially enforce programming that much more closely resembles Legos.
Complicating that problem is that FORTRAN is relatively cryptic, even to cognoscenti. That means intelligibility to any reviewer, or even the author more than a few days after the fact, is very dependent upon comments embedded in the code. In contrast, well written code in a structured language is essentially self-documenting; no comments are required because the program statements are self-evident.
This is about far more than scoring style points. The modeled climate is not really the squiggly line depicting temperature deviation over time: that line -- the "results" -- is the visual manifestation of the interaction between data and code. It has no independent existence whatsoever. Therefore, in order to replicate the results, both data and code must be readily available AND comprehensible.
Hiding behind idiosyncratic programming is to write a blank check for every manner of programming sins; suggesting that an independent audit yielding contradictory results would be considered as disproof of accepted wisdom is, at best, touchingly naive. As the development of Linux has shown, by far the best approach would have been to open-source the software development. Instead, what we have is the worst method imaginable: secretive development by those whose specialty, whatever it might be, is most assuredly not software engineering.
Back in the day, when I was dealing with Structured Query Language, had I produced anything within a cannon-shots distance of being as bad as the CRU's climate modeling programs, I would have been fired faster than that cannon ball came out of the barrel.
Google "cru climategate source code fortran". You will not find anything that is as close to complimentary as I have been. Here is just one example.
By and large, when it comes to climate, and the changing thereof, my ignorance is fairly prodigious. I know some physics and chemistry, and can sometimes discern statistics from cuisine. However, I must admit that my disinclination towards AGW is derived at least as much from temperamental and non-climate bases as from any knowledgeably reasoned conclusions about climatologists' consensus.
Since ClimateGate, though, I can add knowledge to reflex. While I bow to AOG in all computer matters, my ignorance here is not total: I have a graduate degree in computer science, and have spent a couple previous lives in the field putting daily bread on the table.
With regard to the programming that is, in effect, the climate of the future:
Ben Santer, still at the Lawrence Livermore National Lab, did not want to spend his time making his line-by-line computer program accessible to public perusal. He knew – and obviously so did his attackers – that the programming codes would be virtually useless to any one trying to replicate his results. … Personal codes are so idiosyncratic to the programmers that it could take months to explain them to others who could, in much shorter time, do an independent audit by building their own code using the same equations or data sets.Ben Santer is a climate modeler at the Lawrence Livermore Laboratory; the quote comes from Steven Schneider's autobiographical Science as a Contact Sport, pages 147-8.
This is complete, unadulterated, distilled, thoroughgoing essence of nonsense. There is simply no charitable explanation that doesn't involve lavish accusations of ignorance or disingenuousness.
Most climate modeling is done in FORTRAN. Despite being one of the oldest high-level languages, it is still one of the most popular for numerically intensive applications. This largely due to its long term presence on mainframe computers; by mainframes' very nature, languages developed for them (see also COBOL) will be much more persistent than those developed since the advent of personal computers. (Update: per rchrd's comment, I should add that Fortran is still widely used because it is efficient, portable, and, perhaps most importantly, well understood. For demanding numerical applications, SFAIK, it is the gold standard. Corrections are underlined below.)
However, the FORTRAN versions used in most, if not all, climate models has some significant shortcomings.
Foremost among them is that, prior to FORTRAN 2003, it was a procedural language, as opposed to structured. FORTRAN allows code that is as difficult to follow as a bowl of spaghetti; modern structured languages essentially enforce programming that much more closely resembles Legos.
Complicating that problem is that FORTRAN is relatively cryptic, even to cognoscenti. That means intelligibility to any reviewer, or even the author more than a few days after the fact, is very dependent upon comments embedded in the code. In contrast, well written code in a structured language is essentially self-documenting; no comments are required because the program statements are self-evident.
This is about far more than scoring style points. The modeled climate is not really the squiggly line depicting temperature deviation over time: that line -- the "results" -- is the visual manifestation of the interaction between data and code. It has no independent existence whatsoever. Therefore, in order to replicate the results, both data and code must be readily available AND comprehensible.
Hiding behind idiosyncratic programming is to write a blank check for every manner of programming sins; suggesting that an independent audit yielding contradictory results would be considered as disproof of accepted wisdom is, at best, touchingly naive. As the development of Linux has shown, by far the best approach would have been to open-source the software development. Instead, what we have is the worst method imaginable: secretive development by those whose specialty, whatever it might be, is most assuredly not software engineering.
Back in the day, when I was dealing with Structured Query Language, had I produced anything within a cannon-shots distance of being as bad as the CRU's climate modeling programs, I would have been fired faster than that cannon ball came out of the barrel.
Google "cru climategate source code fortran". You will not find anything that is as close to complimentary as I have been. Here is just one example.