The Proof Behind the CRU Climategate Debacle: (false claim alert ?)

Cube Antics ^ | 12/3/09 | Robert Greiner

[crescen7]

I’m coming to you today as a scientist and engineer with an agnostic stand on global warming.

If you don’t know anything about “Climategate” (does anyone else hate that name?) Go ahead and read up on it before you check out this post, I’ll wait.

Back? Let’s get started.

First, let’s get this out of the way: Emails prove nothing. Sure, you can look like an unethical asshole who may have committed a felony using government funded money; but all email is, is talk, and talk is cheap.

Now, here is some actual proof that the CRU was deliberately tampering with their data. Unfortunately, for readability’s sake, this code was written in Interactive Data Language (IDL) and is a pain to go through.

NOTE: This is an actual snippet of code from the CRU contained in the source file: briffa_Sep98_d.pro

[crescen7]

Ok, I don't know what to make of this. Quotes from this article have been showing up in several places. (I searched but hadn't found it posted here before) There's a problem with this analysis. He quotes the source code this:(screenshot from the article)

But the actual file looks like this:(screen shot from the file)

The analysis deals with a grossly edited file (or perhaps my original download was somehow corrupted) - in either case :

The article takes lines 32 through 39 and analyzes them as consecutive lines 1 through 8. It also ignores that there are at least 3 other versions of this single program - and that in this program the "fudge factor" doesn't plot when the program runs. In any case there are at least 2 versions of this same file circulating now, and this "smoking gun" may now be pointing in the other direction.

[kidd]

this "smoking gun" may now be pointing in the other direction

While the code in its entirety has not yet been explored, the author only claims that the array 'valadj' bears a striking resemblence to the hockey stick. He then notes that the data is interpolated with the 'valadj' array.

I've filed this one away as "curious". Not as proof of anything.

I think it's extrordinary that you think that this reverses things (????). It proves nothing.

[crescen7]

“I think it’s extrordinary that you think that this reverses things (????). It proves nothing.”

Sorry, I didn’t mean to imply that this “reverses things” in a general sense. Only in the sense of this particular analysis.

It provides STRONG suspicion (in this case) that the “evidence” has been tampered with to provide a “smoking gun” against the CRU. But if the file is tampered with - then the only thing this proves is that someone is guilty of evidence tampering.

[Bulwinkle]

Hmmm.... are you sure you are looking are the ‘same’ programs?? I’m a total lame-man

Briffa- Harris-tree...matchs the original site:
http://di2.nu/foia/harris-tree/briffa_sep98_e.pro

Briffa - Osborn-tree matchs your post:
http://www.di2.nu/foia/osborn-tree6/briffa_sep98_d.pro

Again, I’m a total lame-mam, just peeking at the stuff

[crescen7]

"Hmmm.... are you sure you are looking are the ‘same’ programs??"

He clearly identifies it as d.pro ; which is what I compared it to. The article doesn't reference a path only the title. There is no e.pro version in "osborn-tree6" but there are a.pro, b.pro, c.pro, and d.pro versions.

The e.pro file you reference is yet another version of this program - but it still doesn't look like what was in the article. (another screen shot - kept the title in this time)



Darn good catch though ! Makes it more confusing than ever!

[Question_Assumptions]

In this programmer’s experience, briffa_sep98_e.pro should be a revision of briffa_sep98_d.pro. While there is a lot of poor interpretation going on about what these guys were up to, the bottom line is that there isn’t just one fishy bit here but a lot of them. Avoiding legitimate FOIA requests, requests and threats to delete emails and data, admission that the models and proxies don’t model real temperaturs, and the whole harry_read_me.txt file that describes what a mess the CRU code is. And if I’m not mistaken, members of the press had this data well before it was released on the web, which strongly suggests it was a leak, not a hacking. This is a little game the left plays very well — break a forest issue down into a bunch of trees, pick one or two that are easy to chop down, chop them down and claim the forest doesn’t exist. I’m not playing.

[Bulwinkle]

Confusing??? AAAAHH!!!!

Stop me before I google again!!!!

osborn-tree6
http://sentinelgetfit.kore-net.com/documents/osborn-tree6/

http://servv89pn0aj.sn.sourcedns.com/~gbpprorg/mil/mindcontrol/global_warming_hoax/documents/osborn-tree6/index.html

[crescen7]

"This is a little game the left plays very well — break a forest issue down into a bunch of trees, pick one or two that are easy to chop down,"

This was essentially my point in making this post. This supposed "smoking gun" analysis is a tree that is easily chopped down. We don't need to go around citing "proofs" that are fodder for the other side.

BTW, the most current files are only 7 (11/12) days older than the first in reports of this leak (11/19) - the media couldn't have had it for very long.

[crescen7]

Yes both of those links contain the file “briffa_sep98_d.pro” and they both look exactly like the “briffa_sep98_d.pro” that I posted a screen shot of - not like the file identified in the article.

[steelyourfaith]

 

Beam me to Planet Gore !

[arthurus]

I think it was sent to BBC a week before it went to the Russian server. BBC sat on it which is, I suspect, why it went to the Russian server.

[Question_Assumptions]

A BBC reporter said that he was sent some of the leaked emails from the Climatic Research Unit at the University of East Anglia more than a month ago – but did nothing about them. That strongly suggests that this is a leak, not a hacking.

[Question_Assumptions]

What I think these programs do show (since they are timestamped as early as 1998) is that someone was playing around with applying adjustments and two more of the programs are called briffa_sep98_decline1.pro and briffa_sep98_decline2.pro, with the same timestamp as briffa_sep98_e.pro and an earlier timestamp than briffa_sep98_d.pro. Both d and e have the same valadj but in different places. I suspect that at some point, someone is going to run the data through them and we’ll know whether the adjustment was applied or not.

[crescen7]

"I suspect that at some point, someone is going to run the data through them and we’ll know whether the adjustment was applied or not."

Well, actually no, you don't. The source code is clear - at least in briffa_sep98_d.pro - which is what the author of this article states as his source. At the risk of sounding overly geeky just look at the next few lines:

;
;filter_cru,5.,/nan,tsin=yyy+yearlyadj,tslow=tslow
;oplot,timey,tslow,thick=5,color=20
;

this is where the result of the previous interpol function that includes the fudge factor (yearlyadj); is added to yyy and then sent to the plotter. But, it's been commented out.

The ";" at the start of the line tells the compiler to ignore these lines. These ";" marks appear in every version of this file that I've found. (3 so far). And in the very next lines:

filter_cru,5.,/nan,tsin=yyy,tslow=tslow
oplot,timey,tslow,thick=5,color=21


which has no ; marks, the plot is run without using the "fudge factor" at all. As you can see, its now plotting "yyy" not "yyy+yearlyadj"

So . . .

This file, which has now been touted as a "mushroom cloud" on several sites - does not even plot the "fudge factor" that it creates. Anyone who uses this file as "proof" of nefarious action on behalf of the CRU had better be aware of the fact that it ignores the "artificial adjustment" - or else they're going to look foolish.

[Redcloak]

The problem with the commented out code is that it shouldn't have been there in the first place. There's no place for code like that in real science; "it's not cricket", as one might say across the pond. The result of those lines of code, commented out or not, is that we are left wondering if any materials presented to the public by East Anglia were plotted with the fudge factor active. Everything that was touched by East Anglia is now suspect.

[crescen7]

"The problem with the commented out code is that it shouldn't have been there in the first place."

Unfortunately, we have no way of knowing that - because we have no idea of what this particular program, out of hundreds of IDL and Fortran programs found in the files, was used for. There are innumerable reasons why one may wish to introduce a random variable in a test plot, if nothing else just to test the plot boundaries of the output medium.

But that's all besides the point.

The point is - everyone needs to bring their "A" game to this argument. The article which this post references calls this "proof positive" of nefarious intent. It is no such thing.

If the article would state the truth, as you just did - it's commented out, but why is it in there in the first place? Then we have an informed criticism of the code and a reasonable question with which to demand further disclosure.

But if one claims to show "definitive proof" and ignore the fact that "the proof" doesn't run in the program - the claim can be easily made to just look foolish.

[Question_Assumptions]

I'm a programmer and I know what comments are. There are two problems with your analysis. The first is that there is a briffa_sep98_e.pro where applying the "artificial correction" isn't commended out. Curiously, it has a timestamp in the archive earlier than briffa_sep98_d.pro, which brings me to my second point. The second is that one way to run a program two different ways is to have both sets of code in the program with one set commented out and the other not commented. If you want to run it the other way, you switch the comments. Yes, the correction is commented out in briffa_sep98_d.pro but there are another two lines that show that what I'm talking about is what happened:

;legend,['Northern Hemisphere April-September instrumental temperature',$
; 'Northern Hemisphere MXD',$
; 'Northern Hemisphere MXD corrected for decline'],$
; colors=[22,21,20],thick=[3,3,3],margin=0.6,spacing=1.5
legend,['Northern Hemisphere April-September instrumental temperature',$
'Northern Hemisphere MXD'],$

I other words, this program was run in different ways with the legends 'Northern Hemisphere MXD', 'Northern Hemisphere MXD corrected for decline', and 'Northern Hemisphere April-September instrumental temperature'. We don't know which way was actually used.

[crescen7]

So the problem with my analysis of briffa_sep98d.pro is that there is another program that wasn’t referenced in the article? Or that one can re-write the leaked code to run it a different way?

Both valid, if not obvious points, but neither mentioned in the original article that calls 8 lines of code a “smoking gun”.

Which again is the point of the post.

People need to be careful quoting “evidence” that they don’t understand. To put it bluntly, it’s possible that the original author of this article intended it as a “plant” to be rather easily discredited. One, the article alters the code (he changed the line numbers and omitted the 1st 32 lines of the program; and failed to mention the “artificial correction” was never applied.

Yes, a similar correction was applied in a different program that is in a different subdirectory. But why not quote that program then?

ps. I’m not following your take on the code quote. I’m no IDL expert (most of my work was in C, and that was some time ago); but it looks like a Legend title block being sent to the printer to me, and it doesn’t include the “corrected” for decline version. Or am I missing something?

[Question_Assumptions]

I think you are correct that people need to be careful. However the comments suggest that the code was, at some point, run. And my overall point is that none of the programs mean anything unless we know they were actually used to process data and that should be clear if people start testing them.

[Question_Assumptions]

As for the comments, my point is that someone also changed the legend, which suggests that the adjusted version was run at some point. Since the timestamp is after the “e” version, it’s possible that someone decided to undo the adjustments. Which set of data they actually used, if any, the adjusted or unadjusted or maybe this was just experimental code, can’t be known without comparing what they released against the original data. That’s the hard work step to really prove whether they did or didn’t do something wrong here. I think it’s also possible that the author of the blog entry meant to code the “e” version and wound up linking to the “d” version, instead. Your point about care is a good one. My point is that the the commenting still doesn’t entirely let them off the hook.