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.