Ce billet est la suite de «LaPresse : Les leçons du ClimateGate (3e partie)», qui se veut une réponse à un article publié dans le journal LaPresse le 8 mai dernier: «Climategate: les leçons sont ailleurs».
Après mon exposé sur le code de programmation diffusé par le ClimateGate (3e partie), je poursuis ma critique de l’article de LaPresse avec un thème similaire, peu rapporté par les médias, et révélateur de la qualité des données des stations : le carnet de bord de Mike Harris (c’est-à-dire le fichier HARRY_READ_ME.txt).
Cette série d’articles en lien au ClimateGate est une opportunité de couvrir la nouvelle, car au moment de traiter le scandale à l’hiver dernier, j’avais dû passer à côté, faute de temps.
Voici la liste des différentes parties de cette série, pour un accès rapide :
- LaPresse : Les leçons du ClimateGate (1ère partie)
- LaPresse : Les leçons du ClimateGate (2e partie – les courriels)
- LaPresse : Les leçons du ClimateGate (3e partie – le code)
- LaPresse : Les leçons du ClimateGate (4e partie – le journal de bord) – le présent billet!
- LaPresse : Les leçons du ClimateGate (5e partie – le 4e rapport du GIEC)
- LaPresse : Les leçons du ClimateGate (6e partie – les enquêtes)
- LaPresse : Les leçons du ClimateGate (7e partie – conclusion)
Tel que discuté dans les parties précédentes, une fuite de documents du Climatic Research Unit (CRU) de l’Université d’East Anglia a révélé au grand public (du moins une partie, puisque les médias ont habilement étouffé l’affaire) qu’une poignée d’experts en climatologie, à l’origine des données de températures, auraient gravement enfreint les règles d’éthique en science pour faire croire à un réchauffement climatique sans précédent, dû aux rejets de CO2 par l’homme. Le scandale porte le nom de ClimateGate.
Le matériel rendu disponible est composé de 1073 courriels et 3585 fichiers, regroupé dans un dossier compressé : FOIA.zip (62MB). Vous pouvez le télécharger sur ce site, ou encore naviguer et consulter les fichiers en ligne directement ici.
Les courriels du ClimateGate nous ont apporté des informations sur la collusion de scientifiques pour cacher des données, manipuler celles-ci à leur avantage et contrôler la publication de travaux scientifiques sur le sujet.
(voir LaPresse: Les leçons du ClimateGate (2e partie – les courriels))
Le code de programmation montre pour sa part certaines manipulations dans les programmes de comptabilisation et d’harmonisation des données, particulièrement en vue de cacher le déclin des années post 1960. Rappelons que les températures des derniers 1000 ans sont calculées à partir de proxys (surtout des cernes d’arbres), mais ceux-ci n’indiquent plus de réchauffement à partir de 1960, au contraire! On a donc subtilement remplacé les dernières décennies par les données de stations météo terrestres (qui elles montrent une augmentation, principalement attribuable à l’effet de chaleur urbaine – et non le CO2), une astuce détaillée à plusieurs reprises dans les commentaires du programmeur.
(voir LaPresse: Les leçons du ClimateGate (3e partie – le code))
Parmi les nombreux documents diffusés, il y en a un qui attire particulièrement l’attention: HARRY_READ_ME.txt. Ce fichier est une sorte de carnet de bord de Mike Harris, employé du CRU et responsable de l’assemblage des données brutes en provenance des différentes stations du monde. Le contenu du carnet couvre la période 2006-2009.
On y trouve des renseignements utiles qui en disent long sur l’état piteux des données reçues (dédoublement de stations, stations inexistantes, grandes périodes sans données…) et les manipulations douteuses apportées pour y remédier (jusqu’à les inventer!).
Voici quelques extraits :
Les données de l’Australie semblent très problématiques, voir inquiétantes. Au-delà des stations en mauvais état (en supposant que leur état soient similaire à celles aux États-Unis, où 90% ne répondent même pas aux critères établis par le National Weather Service (pdf)), il y a les données en trop, donc possiblement surreprésentation… Si peu de rigueur n’augure guère confiance sur la validité des températures globales qui en découlent…
Malheur, le problème serait généralisé! Décidément, il y a de quoi rester perplexe devant les chiffres annoncés par le GIEC (qui prend ses données du CRU, où travaille Mike Harris, celui qui écrit ces lignes).
À la lecture de ce commentaire, on se demande si les gens qui ont récolté les données savaient ce qu’ils faisaient! Le travail semble avoir été bâclé depuis le début, et on peut demeurer sceptique sur la qualité des données harmonisées par Harris, même avec les meilleures intentions du monde.
Rassurés? Moi non. Lorsque les données sont manquantes, on les invente… La climatologie repose sur des données non uniformes dans le temps et l’espace, et doit composer avec des méthodes statistiques pour compléter les trous, tout en leur accordant un poids correct dans l’équation. Une lourde tâche statistique qui requiert une expérience solide. Vu l’état des données et la façon dont on applique les correctifs, on peut fortement douter de la qualité du travail et de sa valeur scientifique. N’oublions pas que tout ceci est fait avec l’idée préconçue du réchauffement par l’homme, donc les données additionnelles risquent fort de pencher en ce sens.
Au risque de me répéter, ça en dit long sur la qualité du travail et ce qui peut en sortir… Et dire qu’on base décisions à coup de milliards de dollars sur ce genre de données!
Sans commentaire :-)
Tags: ClimateGate
De toutes les horreurs auxquelles j’ai été exposé en lisant les documents rendus publics dans le cadre de ce qu’on appelle le Climategate, c’est à coup sûr ce fichier nommé HARRY_READ_ME.txt qui m’a le plus estomaqué.
On doit quand même réserver un peu de pitié au dénommé Mike Harris car on s’aperçoit qu’il a manifestement été engagé pour réparer les pots cassés, causés par l’incompétence de ses prédécesseurs au Climate Research Unit.
Monsieur Pelletier a effectivement mis le doigt sur certains des joyaux de ce long texte qui fait 187 pages lorsque sauvegardé en format pdf. Mais je crois également avoir déniché d’autres petites perles dont, j’espère, seront ravis les lecteurs de ce blogue.
Lorsque l’on voudra vous faire croire que “The science is settled” et que l’on tentera de vous convaincre de dépenser des milliards de milliards basé sur ces données, relisez tous ce magnifique document.
Et voilà les perles
page 1
Had a hunt (hunch?) and found an identically-named temperature database file which did include normals lines at the start of every station. How handy – naming two different files with exactly the same name and relying on their location to differentiate! Aaarrgghh!!
J’ai eu une intuition et j’ai trouvé un fichier des données de températures avec un nom identique qui affichait des lignes normales au début de chaque station. Combien pratique – on accorde à deux fichiers différents le même nom pour ensuite dépendre de leur emplacement pour les différencier! Aaarrgghh!!
page 17
Tried running anomdtb.f90.. failed because it couldn’t find the .dts file! No matter that it doesn’t need it – argh! Examined existing .dts files.. not sure what they’re for.
Ai tenté d’exécuter anomdtb.f90 sans succès parce que le programme ne pouvait trouver le fichier .dts. Peu importe le fait que le programme n’en n’aie pas besoin – argh! Ai examiné les fichiers .dts.. pas certain de ce à quoi ils servent.
page 22
Ran ‘anomdtb’ – got caught out by the requirement for a companion ‘.dts’ file again, ran ‘falsedts.for’ and carried on.. would still be nice to be sure that it’s not something meaningful **sigh**.
Ai exécuté ‘anomdtb’ – et me suis encore fait prendre par l’exigence d’un fichier .dts accompagnateur ai de nouveau exécuté ‘falsedts.for’ pour ensuite poursuivre normalement.. ce serait tout de même bien que ça ne soit pas quelque chose de pertinent **sigh**.
page 43
But the database stubs that have been entered have not been intelligently named, just truncated – so I have no way of knowing which is which! CRU NEEDS A DATA MANAGER.
Mais les abréviations de la base de données qui ont été utilisées ne l’ont pas été de façon intelligente mais bien simplement tronquées – de sorte qu’il m’est impossible de distinguer laquelle est laquelle! Le CRU A BESOIN D’UN GESTIONNAIRE DE DONNÉES.
page 65-66
but it just shows the state our data holdings have drifted into. Who added those two series together? When? Why? Untraceable, except anecdotally. It’s the same story for many other Russian stations, unfortunately – meaning that (probably) there was a full Russian update that did no data integrity checking at all. I just hope it’s restricted to Russia!!
Mais tout ceci ne fait que démontrer l’état dans lequel nos données ont dérivé. Qui a uni ces deux séries ensemble? Quand? Pourquoi? Intraçable sauf de façon anecdotique. Et on observe le même phénomène pour de nombreuses autres stations russes, ce qui signifie – malheureusement – qu’il y a (probablement) eu une mise à jour complète des données russes sans que l’on ait vérifié l’intégrité des données de quelque manière que ce soit. J’espère seulement que cela ne s’applique qu’à la Russie.
page 67
You can’t imagine what this has cost me – to actually allow the operator to assign false WMO codes!! But what else is there in such situations? Especially when dealing with a ‘Master’ database of dubious provenance (which, er, they all are and always will be).
Vous ne pouvez imaginer l’impact que cela a sur moi – de délibérément permettre à l’opérateur d’assigner de faux codes WMO!! Mais que pouvais-je faire d’autre dans de telles situations? Tout spécialement lorsqu’on doit composer avec une base de données maîtresse de provenance douteuse ( et, hum.. elle le sont toutes et le seront toujours).
Page 69
This took longer than hoped.. running out of disk space again. This is why Tim didn’t save more of the intermediate products – which would have made my detective work easier. The ridiculous process he adopted – and which we have dutifully followed – creates hundreds of intermediate files at every stage, none of which are automatically zipped/unzipped. Crazy. I’ve filled a 100gb disk!
Ceci a pris plus de temps que je l’espérais … et je manque d’espace disque encore une fois. Voilà pourquoi Tim ne sauvegardait pas un plus grand nombre de produits intermédiaires – ce qui aurait rendu mon travail de détective plus facile. Le ridicule processus qu’il a adopté – et que nous avons scrupuleusement suivi – produit des centaines de fichiers intermédiaires à chaque étape du processus, et aucun de ces fichiers n’est automatiquement compressé ou décompressé. De la folie furieuse. J’ai rempli un disque dur de 100 Gb.
page 97
It also assisted greatly in understanding what was wrong – Tim was in fact calculating Cloud Percent, despite calling it Sun Percent!! Just awful.
Ça m’a aussi grandement aidé à comprendre ce qui n’allait pas. De fait Tim calculait des Pourcentages Nuages même si il nommait ceci Pourcentage Soleil!! Tout simplement affreux.
page 182
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.
Je suis bien prêt de tout abandonner, encore une fois. L’histoire qui entoure ceci est d’une telle complexité que je ne peux remonter le cours des événements sans développer un affreux mal de tête qui m’oblige à arrêter. Chaque paramètre possède une histoire tortueuse d’interventions manuelles ou semi automatiques qui font que je ne peux pas recourir à des versions antérieures pour ensuite exécuter le programme “update.prog”. Je détruirais ainsi des tonnes de corrections – aux longitudes et latitudes, aux WMO (hourra!) et plus encore. Alors que diable puis-je faire à propos de toutes ces stations que j’ai en double? Ne pourrais-je pas utiliser “fixdupes.for”? Ce serait parfait sauf que je ne jamais été en mesure de terminer ce programme, constamment redirigé vers d’autres feux à éteindre. Aarrgghhh. J’ai besoin d’un nettoyeur de base de données.
@Michel Lafontaine,
Merci pour les ajouts, spécialement la dernière (p.182). Je seconde, Mike Harris semble avoir hérité d’un travail difficile, c’est-à-dire réconcilier des données en très mauvais état (il ne m’apparait pas comme quelqu’un qui a magouillé volontairement – plutôt pris entre l’arbre et l’écorce). Il a la franchise de noter ses remarques… qui en disent long sur la confiance qu’on peut apporter à ces données.
Ce qui m’irrite, c’est que basé sur d’aussi mauvaises sources, on puisse nous faire avaler un réchauffement et des politiques qui vont coûter TRÈS TRÈS cher… Il se pourrait bien que le réchauffement récent soit beaucoup moindre que ce qu’on nous affirme (c’est d’ailleurs ce que les satellites nous indiquent, lesquels (plus précis et avec une meilleure distribution) divergent de plus en plus des thermomètres.
Quel foutoir!