It just keeps getting worse. Along with statements by the scientists that strongly suggest intentional efforts to suppress alternative points of view and manipulation of the data to get the "right" results, the programs actually used to convert the raw data have a lot of very serious problems. Some of these problems are sloppy programming that raises serious questions as to whether the outputs can be trusted. The comments at Volokh Conspiracy are quite enlightening:
There are four major classes of such bugs known definitively to be in the code.The defenses of this bad programming are enough to make me wonder if I was some sort of weirdo is how I do my job (or did my job, back when I had one):
1) Use of static data or static places: This means the code sometimes stores things in a particular place, but always the same place. If two instances of the code are ever running at the same time, they will step on each other, producing incorrect output. This is the least serious, as someone could simply assure us that they never ran two instances at once. We’d have to trust them on this, but under normal circumstances, that wouldn’t be a disaster.
2) Failure to test for error conditions. In many places, the code fails to test for obviously insane error conditions but just goes on processing. That means that if the input is somehow fundamentally broken, the output may be subtly broken. Again, we don’t have the input to retest.
3) Reliance on the user to select the correct input sets. The code relies on the user to tell it what data to process and doesn’t make sure the data is correct, it must trust the user. CRU had data sets with identical names but fundamentally different data. There’s no way now to be sure uncorrected data wasn’t used where corrected data was appropriate or that data wasn’t corrected twice.
4) Reliance on the user to select the correct run-time options. During the run, many of the programs relied on the user to select the correct options as the run progressed. The options were not embedded in the results. A single mis-key could cause the output to be invalid.
Unfortunately, these types of defects combine in a multiplicative way. A mis-key during a run could result in subtly bad input that could cause an error condition that’s not detected resulting in radically bad output that’s not detected because of lack of input validation ...
Minor quibble here: If the program gives garbage output for “obviously insane” or “fundamentally broken” inputs, this may not be the fault of the program. If I’d spent my time doing input validity tests on all the possible inputs to subroutines I wrote, I wouldn’t get at real work done. At some time, you have to assume some good nature in others, and get on with the tasks at hand. After all, they’re using your code, you aren’t using their data..... Sounds cruel, but if you’ve worked in the field... If they pay me for taking care of their excessive stupidity, then again....Perhaps if I had not written defensive code that checked inputs for validity, I would still be employed writing bad code? Or are the defenses of this absurdity just ad hoc, to make the Climate "Research" Unit look good?
Not to mention, what do you care if the output is wrong for “fundamentally broken” input?
Along with bad programming without dishonest intent, there seems to be dishonest intent as well. John Lott over at Fox News discusses this problem:
But the CRU’s temperature data and all of the research done with it are now in question. The leaked e-mails show that the scientists at the CRU don’t know how their data was put together. CRU took individual temperature readings at individual stations and averaged the information out to produce temperature readings over larger areas. The problem comes in how they did the averaging. One of the leaked documents states that “our flagship gridded data product is produced by [a method that] renders the station counts totally meaningless” and “so, we can have a proper result, but only by including a load of garbage!” There were also significant coding errors in the data. Weather stations that are claimed to exist in Canada aren’t there -- leading one memo to speculate that the stations “were even invented somewhere other than Canada!”Yet as Lott points out, the vast majority of American news media are barely covering this story, if they are covering it at all.
The computer code used to create the data the CRU has used contains programmer notes that indicate that the aggregated data were constructed to show an increase in temperatures. The programmer notes include: “Apply a VERY ARTIFICAL correction for decline!!” and "Low pass filtering at century and longer time scales never gets rid of the trend -- so eventually I start to scale down the 120-yr low pass time series to mimic the effect of removing/adding longer time scales!" The programmers apparently had to try at least a couple of adjustments before they could get their aggregated data to show an increase in temperatures.
All this could in theory be correctable by going back and starting from scratch with the original “raw” data, but the CRU apparently threw out much of the data used to create their temperature measures. We now only have the temperature measures that they created.
UPDATE: For those who insist that this is a tempest in a teapot--even George Monbiot, one of the true believers in AGW, is admitting that the problem is substantial, and that the refusal of a lot of other AGW true believers to admit that the problem is real is a form of a denialism. From the November 25, 2009 Guardian:
I have seldom felt so alone. Confronted with crisis, most of the environmentalists I know have gone into denial. The emails hacked from the Climatic Research Unit (CRU) at the University of East Anglia, they say, are a storm in a tea cup, no big deal, exaggerated out of all recognition. It is true that climate change deniers have made wild claims which the material can't possibly support (the end of global warming, the death of climate science). But it is also true that the emails are very damaging.Now, Monbiot's defense is that the denialists are even less honest. And this justifies the misbehavior we see in the CRU's emails how?
The response of the greens and most of the scientists I know is profoundly ironic, as we spend so much of our time confronting other people's denial. Pretending that this isn't a real crisis isn't going to make it go away. Nor is an attempt to justify the emails with technicalities. We'll be able to get past this only by grasping reality, apologising where appropriate and demonstrating that it cannot happen again.
It is true that much of what has been revealed could be explained as the usual cut and thrust of the peer review process, exacerbated by the extraordinary pressure the scientists were facing from a denial industry determined to crush them. One of the most damaging emails was sent by the head of the climatic research unit, Phil Jones. He wrote "I can't see either of these papers being in the next IPCC report. Kevin and I will keep them out somehow - even if we have to redefine what the peer-review literature is!"
...
When it comes to his handling of Freedom of Information requests, Professor Jones might struggle even to use a technical defence. If you take the wording literally, in one case he appears to be suggesting that emails subject to a request be deleted, which means that he seems to be advocating potentially criminal activity. Even if no other message had been hacked, this would be sufficient to ensure his resignation as head of the unit.
What's also important is to understand how thoroughly non-reproducible the "results" of all this work really is. Some poor programmer named Harry put a very detailed description of his attempts to recreate the temperature data sets in a document called HARRY_READ_ME.txt. (The use of file names with READ_ME or some variant by programmers documenting what they have found is quite common.) If you are a programmer, you will read through this, and sympathize with Harry--but you will also be horrified at how irreproducible the results were of running various programs on existing data sets. Here's one small example:
..not good! Tried recompiling for uealogin1.. AARGGHHH!!! Tim'sSo how did this code work the first time that they created the data? Different hardware and compiler, probably, handled floating point overflow correctly--or the floating point exception simply didn't get reported. So how accurate was the data? Poor Harry also reports on his considerable efforts to recreate some of the data files upon which this whole global warming claim is largely based--and his attempts to verify that running one of these conversion programs actually can recreate the data files that they are current using:
code is not 'good' enough for bloody Sun!! Pages of warnings and
27 errors! (full results in 'anomdtb.uealogin1.compile.results').
17. Inserted debug statements into anomdtb.f90, discovered that
a sum-of-squared variable is becoming very, very negative! Key
output from the debug statements:
OpEn= 16.00, OpTotSq= 4142182.00, OpTot= 7126.00
DataA val = 93, OpTotSq= 8649.00
DataA val = 172, OpTotSq= 38233.00
DataA val = 950, OpTotSq= 940733.00
DataA val = 797, OpTotSq= 1575942.00
DataA val = 293, OpTotSq= 1661791.00
DataA val = 83, OpTotSq= 1668680.00
DataA val = 860, OpTotSq= 2408280.00
DataA val = 222, OpTotSq= 2457564.00
DataA val = 452, OpTotSq= 2661868.00
DataA val = 561, OpTotSq= 2976589.00
DataA val = 49920, OpTotSq=-1799984256.00
DataA val = 547, OpTotSq=-1799684992.00
DataA val = 672, OpTotSq=-1799233408.00
DataA val = 710, OpTotSq=-1798729344.00
DataA val = 211, OpTotSq=-1798684800.00
DataA val = 403, OpTotSq=-1798522368.00
OpEn= 16.00, OpTotSq=-1798522368.00, OpTot=56946.00
forrtl: error (75): floating point exception
IOT trap (core dumped)
..so the data value is unbfeasibly large, but why does the
sum-of-squares parameter OpTotSq go negative?!!
Probable answer: the high value is pushing beyond the single-
precision default for Fortran reals?
Welcome to the GRIM Comparer
Please enter the first grim file (must be complete!): cru_ts_2_10.1961-1970.tmp
Please enter the second grim file (may be incomplete): glo2grim1.out
File glo2grim1.out terminated prematurely after 4037 records.
SUMMARY FROM GRIMCMP
Files compared:
1. cru_ts_2_10.1961-1970.tmp
2. glo2grim1.out
Total Cells Compared 4037
Total 100% Matches 0
Cells with Corr. == 1.00 0 ( 0.0%)
Cells with 0.90<=Corr<=0.99 3858 (95.6%) Cells with 0.80<=Corr<=0.89 119 ( 2.9%) Cells with 0.70<=Corr<=0.79 25 ( 0.6%) ..which is good news! Not brilliant because the data should be identical.. but good because the correlations are so high! This could be a result of my mis-setting of the parameters on Tim's programs (although I have followed his recommendations wherever possible), or it could be a result of Tim using the Beowulf 1 cluster for the f90 work. Beowulf 1 is now integrated in to the latest Beowulf cluster so it may not be practical to test that theory.
Now, getting pretty close is a good thing--but it isn't confidence inspiring that 95.6% of the cells are 90% to 99% correct--and 90% is likely to exceed by many times the supposed global warming. Now, if the errors are randomly distributed, it might not much matter--but I thought that what separated science from humanities is the ability to do mathematical verification.
No comments:
Post a Comment