:banghead: How many times have we said that you cannot contribute a specific weather event to climate change. These things happen without any human intervention, what makes you think AGW had anything to do with it.
Floods however, are probably more prevalent because of Hydroelectric power (aka a green energy
). The more we put up dams the more flooding and other environmental impacts happen down river.
Oh yes, and the melting glaciers, except for the ones that are growing. You realize of course that the flooding has probably been that high in Indiana before. Go look at the flood planes, If her house in in the 100 year flood plane, I bet there was a time when the flooding has been even higher.
Of course, attribution of the “melting glacier” thing … well, some of them, at least, were traced back to a bar room conversation. [mixing bad models*, bad data, and gossip … bad science.]
- if you read that 2010 report, it shows there were really gross errors in the models … really bad stuff … that some sharp-eyed grad student should have spotted on day 1.
[Sigh.]
landshape.org/news/documents/us-senate-climategate-report.pdf
Here are a bunch of quotes from pages 70 and 71: [If these don’t make you cringe, nothing will … and we are supposed to put blind faith on the work product of these people???]
*Back to the gridding. I am seriously worried that our flagship gridded data product is produced by Delaunay triangulation - apparently linear as well. As far as I can see, this renders the station counts totally meaningless. It also means that we cannot say exactly how the gridded data is arrived at from a statistical perspective - since we’re using an off-the-shelf product that isn’t documented sufficiently to say that. Why this wasn’t coded up in Fortran I don’t know - time pressures perhaps? Was too much effort expended on homogenisation, that there wasn’t enough time to write a gridding procedure? Of course, it’s too late for me to fix it too. Meh.
Now looking at the dates… something bad has happened, hasn’t it. COBAR AIRPORT AWS cannot start in 1962, it didn’t open until 1993! Looking at the data - the COBAR station 1962- 2004 seems to be an exact copy of the COBAR AIRPORT AWS station 1962-2004, except that the latter has more missing values. Now, COBAR AIRPORT AWS has 15 months of missing value codes beginning Oct 1993… coincidence? --------
I am seriously close to giving up, again. The history of this is so complex that I can’t get far enough into it before by head hurts and I have to stop. Each parameter has a tortuous history of manual and semi-automated interventions that I simply cannot just go back to early versions and run the update prog. I could be throwing away all kinds of corrections - to lat/lons, to WMOs (yes!), and more.
So what the hell can I do about all these duplicate stations? Well, how about fixdupes.for? That would be perfect - except that I never finished it, I was diverted off to fight some other fire. Aarrgghhh.
I - need - a - database - cleaner.
What about the ones I used for the CRUTEM3 work with Phil Brohan? Can’t find the bugger!! Looked everywhere, Matlab scripts aplenty but not the one that produced the plots I used in my CRU presentation in 2005. Oh, F**K IT. Sorry. I will have to WRITE a program to find potential duplicates. It can show me pairs of headers, and correlations between the data, and I can say
70
‘yay’ or ‘nay’. There is the finddupes.for program, though I think the comment for
this program sums it up nicely:
’ program postprocdupes2 c Further post-processing of the duplicates file - just to show how **** the c program that produced it was! Well - not so much that but that once it was c running, it took 2 days to finish so I couldn’t really reset it to improve c things. Anyway,
this version does the following useful stuff: c (1) Removes and squirrels away all segments where dates don’t match; c (2) Marks segments >5 where dates don’t match; c (3) Groups segments from the same pair of stations; c (4) Sorts based on total segment length for each station pair’
You see how messy it gets when you actually examine the problem?
Well, dtr2cld is not the world’s most complicated program. Wheras cloudreg is, and** I immediately found a mistake! Scanning forward to 1951 was done with a loop that, for completely unfathomable reasons, didn’t include months! So we read 50 grids instead of 600!!! That may have had something to do with it. I also noticed, as I was correcting THAT, that I reopened the DTR and CLD data files when I should have been opening the bloody station files!!** I can only assume that I was being interrupted continually when I was writing this thing. Running with those bits fixed improved matters somewhat, though now there’s a problem in that one 5-degree band (10S to 5S) has no stations! This will be due to low station counts in that region, plus removal of duplicate values.*
