Saturday, November 21, 2009

Some Pretty Damning Evidence Global Warming Info Has Been Manipuated

You may have heard that the Climate Research Unit, University of East Anglia, has suffered a break in and hundreds of electronic files and e-mails were posted to the internet. The information contained in these files seems to show a clear cut, repeated pattern of data manipulation, withholding data from those not "onboard" with CO2 Global Warming, and coming up with tricks to explain away the cooling that was taking place when warming was predicted.

You can download these files from here. Some interesting excerpts from them are below. The names of the scientists involved are literally a "who's who" in the CO2 Global Warming community.

From Michael E. Mann (witholding of information / data):

Dear Phil and Gabi,
I’ve attached a cleaned-up and commented version of the matlab code that I wrote for doing the Mann and Jones (2003) composites. I did this knowing that Phil and I are likely to have to respond to more crap criticisms from the idiots in the near future, so best to clean up the code and provide to some of my close colleagues in case they want to test it, etc. Please feel free to use this code for your own internal purposes, but don’t pass it along where it may get into the hands of the wrong people.


From Nick McKay (modifying data):
The Korttajarvi record was oriented in the reconstruction in the way that McIntyre said. I took a look at the original reference – the temperature proxy we looked at is x-ray density, which the author interprets to be inversely related to temperature. We had higher values as warmer in the reconstruction, so it looks to me like we got it wrong, unless we decided to reinterpret the record which I don’t remember. Darrell, does this sound right to you?


From Tom Wigley (acknowleding the urban effect):
We probably need to say more about this. Land warming since 1980 has been twice the ocean warming — and skeptics might claim that this proves that urban warming is real and important.


From Phil Jones (modification of data to hide unwanted results):
I’ve just completed Mike’s Nature trick of adding in the real temps to each series for the last 20 years (ie from 1981 onwards) amd from 1961 for Keith’s to hide the decline.


From Kevin Trenberth (failure of computer models):
The fact is that we can’t account for the lack of warming at the moment and it is a travesty that we can’t. The CERES data published in the August BAMS 09 supplement on 2008 shows there should be even more warming: but the data are surely wrong. Our observing system is inadequate.


From Michael Mann (truth doesn't matter):
Perhaps we'll do a simple update to the Yamal post, e.g. linking Keith/s new page--Gavin t? As to the issues of robustness, particularly w.r.t. inclusion of the Yamal series, we actually emphasized that (including the Osborn and Briffa '06 sensitivity test) in our original post! As we all know, this isn't about truth at all, its about plausibly deniable accusations.


From Phil Jones (witholding of data):
The skeptics seem to be building up a head of steam here! ... The IPCC comes in for a lot of stick. Leave it to you to delete as appropriate! Cheers Phil
PS I’m getting hassled by a couple of people to release the CRU station temperature data. Don’t any of you three tell anybody that the UK has a Freedom of Information Act !


From Michael E. Mann (using a website to control the message, hide dissent):
Anyway, I wanted you guys to know that you’re free to use RC [RealClimate.org - A supposed neutral climate change website] Rein any way you think would be helpful. Gavin and I are going to be careful about what comments we screen through, and we’ll be very careful to answer any questions that come up to any extent we can. On the other hand, you might want to visit the thread and post replies yourself. We can hold comments up in the queue and contact you about whether or not you think they should be screened through or not, and if so, any comments you’d like us to include.


From Phil Jones (witholding of data):
If FOIA [Freedom Of Information Act] does ever get used by anyone, there is also IPR [Intellectual Property Rights] to consider as well. Data is covered by all the agreements we sign with people, so I will be hiding behind them.


From Phil Jones (destroying of emails / evidence):
Mike, Can you delete any emails you may have had with Keith re AR4? Keith will do likewise. He’s not in at the moment – minor family crisis. Can you also email Gene and get him to do the same? I don’t have his new email address. We will be getting Caspar to do likewise.


From Tom Wigley (data modification):
Phil, Here are some speculations on correcting SSTs to partly explain the 1940s warming blip. If you look at the attached plot you will see that the land also shows the 1940s blip (as I’m sure you know). So, if we could reduce the ocean blip by, say, 0.15 degC, then this would be significant for the global mean — but we’d still have to explain the land blip. I’ve chosen 0.15 here deliberately. This still leaves an ocean blip, and i think one needs to have some form of ocean blip to explain the land blip (via either some common forcing, or ocean forcing land, or vice versa, or all of these). When you look at other blips, the land blips are 1.5 to 2 times (roughly) the ocean blips — higher sensitivity plus thermal inertia effects. My 0.15 adjustment leaves things consistent with this, so you can see where I am coming from. Removing ENSO does not affect this. It would be good to remove at least part of the 1940s blip, but we are still left with “why the blip”. Let me go further. If you look at NH vs SH and the aerosol effect (qualitatively or with MAGICC) then with a reduced ocean blip we get continuous warming in the SH, and a cooling in the NH — just as one would expect with mainly NH aerosols. The other interesting thing is (as Foukal et al. note — from MAGICC) that the 1910-40 warming cannot be solar. The Sun can get at most 10% of this with Wang et al solar, less with Foukal solar. So this may well be NADW, as Sarah and I noted in 1987 (and also Schlesinger later). A reduced SST blip in the 1940s makes the 1910-40 warming larger than the SH (which it currently is not) — but not really enough. So … why was the SH so cold around 1910? Another SST problem? (SH/NH data also attached.) This stuff is in a report I am writing for EPRI, so I’d appreciate any comments you (and Ben) might have. Tom.


From Thomas R Karl (witholding data) :
We should be able to conduct our scientific research without constant fear of an "audit" by Steven McIntyre; without having to weigh every word we write in every email we send to our scientific colleagues. In my opinion, Steven McIntyre is the self-appointed Joe McCarthy of climate science. I am unwilling to submit to this McCarthy-style investigation of my scientific research. As you know, I have refused to send McIntyre the "derived" model data he requests, since all of the primary model data necessary to replicate our results are freely available to him. I will continue to refuse such data requests in the future. Nor will I provide McIntyre with computer programs, email correspondence, etc. I feel very strongly about these issues. We should not be coerced by the scientific equivalent of a playground bully. I will be consulting LLNL's Legal Affairs Office in order to determine how the DOE and LLNL should respond to any FOI requests that we receive from McIntyre.


From Tom Wigley (ousting of a skeptic from a professional organization):
Proving bad behavior here is very difficult. If you think that Saiers is in the greenhouse skeptics camp, then, if we can find documentary evidence of this, we could go through official AGU channels to get him ousted.


From Phil Jones (forging of dates):
Gene/Caspar, Good to see these two out. Wahl/Ammann doesn't appear to be in CC's online first, but comes up if you search. You likely know that McIntyre will check this one to make sure it hasn't changed since the IPCC close-off date July 2006! Hard copies of the WG1 report from CUP have arrived here today. Ammann/Wahl - try and change the Received date! Don't give those skeptics something to amuse themselves with.


From a document titled "jones-foiathoughts.doc" (witholding of data):
Options appear to be:
1. Send them the data
2. Send them a subset removing station data from some of the countries who made us pay in the normals papers of Hulme et al. (1990s) and also any number that David can remember. This should also omit some other countries like (Australia, NZ, Canada, Antarctica). Also could extract some of the sources that Anders added in (31-38 source codes in J&M 2003). Also should remove many of the early stations that we coded up in the 1980s.
3. Send them the raw data as is, by reconstructing it from GHCN. How could this be done? Replace all stations where the WMO ID agrees with what is in GHCN. This would be the raw data, but it would annoy them.


From Mick Kelly (modifying data to hide cooling):
Yeah, it wasn’t so much 1998 and all that that I was concerned about, used to dealing with that, but the possibility that we might be going through a longer – 10 year – period of relatively stable temperatures beyond what you might expect from La Nina etc. Speculation, but if I see this as a possibility then others might also. Anyway, I’ll maybe cut the last few points off the filtered curve before I give the talk again as that’s trending down as a result of the end effects and the recent cold-ish years.


References:
Zip File of Data Taken By Hacker
The Blackboard Blog On This Issue
Philadelphia Examiner Article

Thursday, October 15, 2009

First Release Of Redesigned Particle Code Is Up


The first release of the redesigned Particle code is up and can be downloaded from SourceForge.

What's In This Release
The code has the following features:

* It has been placed in the public domain.
* Particle base class that is independent of FreePOOMA.
* Particle classes for all observed Hadrons of the Standard Model, this is in addition to the elementary particles.
* Particle decay functionality added.
* Template-based classes that allow for any type of number to be used for particle properties. For example, you can use floats, doubles, complex numbers, or quaternions for these properties.
* Math utilities that provide matrixes, vectors, vertexes, and quaternion classes.
* Programmer's Guide in both Microsoft Word and Apple Pages formats.

What's Not In This Release
This is basically a 'To Do' list. These features will be added in the near future pretty much in the order listed below.

* FreePOOMA integration. This will be added in the form of a wrapper class around the new Particle classes.
* Collision detection and reaction code.
* An atomic model, i.e. a way to combine particles into atoms.
* A molecular model, i.e. a way to combine atoms into molecules.
* Support for fields.
* OpenGL integration.

Once again I'd like to thank the folks at The Particle Data Group for helping me when I ran into problems.

The code is available as a zip file here: Particle Zip File.

In the future I'll be making posts that cover the code in a bit more detail.

Friday, September 25, 2009

An Oldie But A Goodie On Global Warming And Cosmic Rays


Here's a chart I put together a few years ago on the connection between cosmic rays and global temperatures. The red line shows changes in galactic cosmic rays hitting the earth, the blue line shows changes in low level cloud cover. The black line shows changes in global temperature averages. We can see that as global cosmic rays increase, low level cloud cover increases. And as low level cloud cover increases, global temperature averages go down.

The data shown covers the period of 1984 through 2002.

Wednesday, September 23, 2009

Quantum Physics Safe, For Now

The Particle Data Group has responded to the letter I sent them regarding the strange behavior of the Strange D, which seemed to not conserve charge in its decays. Their response is that the decay in question is really the sum of two different decays. The two actual decays are listed below the summed decay. I checked and using those two decays does indeed work correctly. As far as I know, the Strange D is the only particle that uses this "summed" notation.

Anyway, while I was waiting to hear back from them I found another unusual decay that doesn't seem to conserve charge: the Charmed Lambda. Decay #10 of this particle gives a decay whose total charge is neutral, whereas the Charmed Lambda has a negative charge. And there's no "summed" notation for this particle as far as I can see. So I've written off another letter hoping they're nice enough to respond once more.

That said, the extended Particle class is nearly done. Once these remaining few issues are cleared up, it'll be published.

Reference
Charmed Lambda Info: http://pdg.lbl.gov/2009/listings/rpp2009-list-lambdac-plus.pdf

Saturday, September 12, 2009

Apple Open Sources Grand Central Dispatch

Apple has released the source code for Snow Leopard's new Grand Central Dispatch under an Apache-style license. Grand Central Dispatch lets programmers easily take advantage of modern multi-core hardware. The Apache licensing means it can be safely used in projects wishing to keep the rest of their code proprietary. This is great news for folks writing code that needs lots of horsepower and needs to run on multiple platforms.

Links:
Grand Central Dispatch code at Mac OS Forge
MacResearch article discussing the release
Apple's Grand Central Dispatch Technology Briefing
Introducing Blocks and Grand Central Dispatch (Must be a registered Apple Developer to access this article)

Technical Note For Windows Programmers: Grand Central Dispatch uses a technology known as Blocks. Blocks require a language extension to C or C++ known as Lambdas. This language extension has been added to the publicly available GCC compiler and has been submitted for inclusion for the next version of the C programming language. But I don't think it's part of Microsoft's Visual Studio development environment. The proposed extension differs syntactically from Microsoft's Lambda extension. Bottom line, if you want to use Grand Central Dispatch on Windows, you'll want to use the GCC compiler.

Tuesday, September 8, 2009

Error In Quantum Physics?

I've been working on adding additional particles for the particle classes I discussed in a previous post. They'll be a lot more particles and more information about each particle. One of the things included is particle decay, when one particle transforms into several different particles. It was while I was working on this that I came across what looks like an error in the measured decays of a particle known as the Strange D.

Particles turning into other particles is neat, but when they do it they have to follow certain conservation laws. One of those laws is that the overall electric charge must be preserved. This means when you add up all the charges from the new particles it has to be exactly the same as the charge for the particle they decayed from.

The Strange D has an electric charge of 1. According to the the Particle Data Group the Strange D can decay into particles known as Eta, Leptons, and Eta Prime. Specifically, the decay (decay #14, btw) looks like this:

Decay
Particle__________________________Charge
Eta_______________________________0
Non-Neutrino Anti Lepton______________1
Neutrino __________________________0
Eta Prime__________________________0
Non-Neutrino Anti Lepton______________1
Neutrino __________________________0
-----------------------------
Total Decay Charge___________________2

Strange D Charge_____________________1

So the total charge of the particles from the decay is 2, while the original particle had only a charge of 1, which violates the conservation of electric charge.

When I discovered the bad redshift data a while back, I first gave the folks who produced the data a chance to respond. So I'm sending off a letter to the Particle Data Group to see if the data is bad, or if it's just a misunderstanding on my part. We'll see what they say.

References
Strange D data from the Particle Data Group
Conservation laws of physics

Tuesday, September 1, 2009

Using POOMA With Excel, OpenGL, and HippoDraw


In a prior post I covered the basics of how you can extract data from POOMA for display in your programs. I'm going to expand on that now and show how you can use POOMA with Excel or Numbers, OpenGL, and HippoDraw. The code discussed in this post can be downloaded from SourceForge at the following locations:

Download POOMAIO.h
Download POOMAIOTest.cpp

POOMAIO.h contains classes for writing POOMA Array values to CSV files, to TNT files, and to a format usable as translate values in OpenGL programs. POOMAIOTest.cpp is the electron bounce program from the previous post re-written to use these new IO capabilities.

To use these new classes, you instantiate them and call their write() method with the appropriate parameters.

Using POOMA Data In Excel Or Numbers
Both Excel and Numbers are spreadsheets that can read CSV (Comma Separated Values) files. POOMIO.h contains a class named VectorCSVOutput that will write POOMA array values in CSV format. VectorCSVOutput is a template that takes the number of dimensions of the POOMA array and the data type of values stored in that array. Once you've instantiated the class, call it's write method passing in the output stream, POOMA array to write, and character delimiter to use. The character delimiter defaults to a comma, and you'll probably want to stick with that. An example that prints the positions of electrons is shown below along with a screen shot of the resulting values as they appear in Numbers.


VectorCSVOutput<3> oVectorCSVOutput;

for (unsigned int iLoop5 = 0; iLoop5 < iNumberOfParticles; iLoop5++)
{
CustomParticle<PTraits_t>::PointType_t oThisElectronPosition = oElectron.pos(iLoop5);

cout << iLoop5 << ","; // Print out the number of each particle.
oVectorCSVOutput.write(cout, oThisElectronPosition);
cout << endl;
} // for



Using POOMA Data In HippoDraw
The next output format we're going to look at is the TNT format. The TNT format can be read by HippoDraw, which is a data analysis tool from SLAC. The class used to write POOMA arrays to the TNT format is VectorTNTOutput, which inherits from VectorCSVOutput. The only additional work you need to do for VectorCSVOutput is to call its writeHeaders() method. The write headers method takes an output stream, a title and a vector of column labels as parameters. An example of using this class is shown below.

VectorTNTOutput<3> oVectorTNTOutput;
vector<string> vLabels;

vLabels.push_back(string("Particle"));
vLabels.push_back(string("X"));
vLabels.push_back(string("Y"));
vLabels.push_back(string("Z"));

oVectorTNTOutput.writeHeaders(cout, string("Electron Bounce"), vLabels);

// .... perform work ....

for (unsigned int iLoop5 = 0; iLoop5 < iNumberOfParticles; iLoop5++)
{
CustomParticle<PTraits_t>::PointType_t oThisElectronPosition = oElectron.pos(iLoop5);

cout << iLoop5 << ",";
oVectorTNTOutput.write(cout, oThisElectronPosition);
cout << endl;
} // for



Using POOMA Data In OpenGL
OpenGL usually only need translations from POOMA. You'll create the objects you want to display as meshes and translate them to their correct location based on data provided by POOMA. However, OpenGL programs often want their position values normalized between a value of -1 and 1 in the X and Y directions and a value of 0.1 and some maximum value in the Z direction. There are two classes to help you with this translation, VectorOpenGLOutput, which writes scaled translation values to standard out as a C array of floats, and VectorOpenGLVectorOutput, which stores scaled translation values in a C++ vector. Both of these classes need to be told what the maximum value will be in your POOMA array and how you want to offset the X, Y, and Z values. The maximum values are used to scale down the values in the array to make them usable by OpenGL. The offset then moves the X, Y, and Z positions so they appear on the screen.

With VectorOpenGLOutput you can write values to standard out, and then cut and paste them directly into C or C++ code for later replay. The example below shows the code to do this.

CustomParticle<PTraits_t>::PointType_t oMaxValues;
CustomParticle<PTraits_t>::PointType_t oOffsets;
VectorOpenGLOutput<3> oVectorOpenGLOutput;

oMaxValues(0) = 99;
oMaxValues(1) = 99;
oMaxValues(2) = 99;
oOffsets(0) = 1;
oOffsets(1) = 1;
oOffsets(2) = -0.1;
cout << "float aTranslate" << iLoop2 << "[" << iNumberOfParticles << "][3]{" << endl;
for (unsigned int iLoop5 = 0; iLoop5 < iNumberOfParticles; iLoop5++)
{
CustomParticle<PTraits_t>::PointType_t oThisElectronPosition = oElectron.pos(iLoop5);

oVectorOpenGLOutput.write(cout, oThisElectronPosition, oMaxValues, oOffsets);
} // for
cout << "};" << endl;


The VectorOpenGLVectorOutput stores the scaled values in an array so you can use them right away in your program. An example is shown below.

CustomParticle<PTraits_t>::PointType_t oMaxValues;
CustomParticle<PTraits_t>::PointType_t oOffsets;
VectorOpenGLVectorOutput<3> oVectorOpenGLVectorOutput;
vector<CustomParticle<PTraits_t>::AxisType_t> vPositions;

oMaxValues(0) = 99;
oMaxValues(1) = 99;
oMaxValues(2) = 99;
oOffsets(0) = 1;
oOffsets(1) = 1;
oOffsets(2) = -0.1;
for (unsigned int iLoop5 = 0; iLoop5 < iNumberOfParticles; iLoop5++)
{
CustomParticle<PTraits_t>::PointType_t oThisElectronPosition = oElectron.pos(iLoop5);

oVectorOpenGLVectorOutput.write(vPositions, oThisElectronPosition, oMaxValues, oOffsets);
// ... Call OpenGL as needed with the values stored in vPositions.
vPositions.clear();
} // for


The OpenGL examples assume a bounding box of 0 through 99 in the POOMA program for the X, Y and Z axis. This means particles cannot travel beyond those dimensions, they'll bounce of the invisible walls instead. This is the condition that was set up in the example program.

The end result of the translation to OpenGL values is the X and Y axis will be scaled to values between -1 and 1, and the Z axis will be scaled to values between 0.1 and 2.1. These scaled values are commonly used by OpenGL programs. Your OpenGL program will use gltranslatef() to translate your 3D representation of the particles using the values provided by VectorOpenGLOutput or VectorOpenGLVectorOutput.