Tuesday, March 16, 2010

What's Wrong With This Picture?

Crazy Data From NASA Or Bugs In My Programs?

While I'm waiting to hear from NASA, I've started doing a QA check both of my code and the Aqua Satellite AMSU data. The above picture shows an example of some of the things I've come across. The picture shows NASA's AMSU channel 5 data for every day in January, 2008, and January, 2009 through January, 2010 for all 30 footprints (14 months total). The view along the X axis is by footprint, with an average at the end. The data was generated by my AMSUSummary program and displayed in Apple Numbers.

You can see the obvious problems with the data. Channels 17 and 18 are just whacked. Channels 25 through 30 go in the wrong direction, and channels 1 through 6 have too high a value. Compare this to the more standard picture of what such a footprint snapshot should look like, shown below.

What 30 Footprints Should Look Like.

Below is the same data again, this time the X axis represents time.


And here's daily data from December 31st, 2009. This data has been through my QA process and none of the scans for channels 24 or 25 passed QA. The QA checks to make sure none of the data is more than +/- 50% of the expected readings as defined in the literature.


So the question is, is this strange data due to bugs in my code, or is this the way the data actually looks. I've already done QA checks on my code, but for this next week, I'll be going over it again to see where the problem lies.

So for the rest of the week expect QA posts from me. In addition to checking out the code and data, these posts will give good instructions on how to use the programs I've written so far.

Monday, March 15, 2010

Request Sent To NASA For Unpublished Data And Algorithms Related To Creation Of Synthetic Channel 4 Data

As discussed in a previous post, NASA now synthesizes channel 4 data of the Aqua AMSU. Going through the steps needed to recreate this synthesis, I noticed several sets of required data are not available to the public. So I've sent off a request for this data as well as the associated (and undocumented, as far as I can tell) AMSU-A Radiative Transfer Algorithm. I've also requested information regarding the depth of the atmosphere each footprint on channel 5 scans so that I can get back to work on recreating the UAH temperatures.

The request was sent a few days ago. Hopefully they'll respond. They've already sent one piece of missing data, the at-launch noise for each channel (that's the NEDTi in the formula at the top of this post). So my thanks to NASA JPL for that.

The requested data is:

● The 230000 cases used to create the values for the vectors Ai and Theta Bar i, or the values of vectors Ai and Theta Bar i themselves if the 230000 readings are no longer available.
● Documentation on how the AMSU-A Radiative Transfer Algorithm actually works.
● Atmospheric scan depth for each footprint on channel 5.

Previous Posts In This Series:



References:
NASA Responds
AIRS/AMSU/HSB Version 5 Modification of Algorithm to Account for Increased NeDT in AMSU Channel 4

Sunday, March 14, 2010

Aqua Satellite Project, Update 3 Released

Update 3 for the Aqua Satellite Project is ready. You can download it here. It includes a new AMSUNormalize program for normalizing temperature data produced by AMSUSummary.

Additionally, a -l flag was added to AMSUExtract and AMSUSummary to pull latitude and longitude values for each footprint being pulled.

Those are the big items. For additional details on the release, see the change log.

Saturday, March 13, 2010

Draw2D JavaScript Graphics Engine Released

Draw2D version 1.0 has just been released and you can get it here.

Draw2D is a JavaScript graphics engine that allows you to add dynamically created shapes to any web page. Draw2D also supports mouse events, allowing shapes to respond to user input. Like all my coding projects, the Draw2D code has been placed in the public domain.

Draw2D will serve as the graphics engine for new features available in the Climate Scientist Starter Kit, Version 2.0. More details on this will be given in future posts.

The download includes source code, several HTML example pages, and a programmer's guide in Apple Pages, Microsoft Word, and Adobe PDF formats.

I'll finish out this post with a few screen shots showing what Draw2D can do.

Points, Lines, Quadradic Curves, Cubic Curves




Triangles And Polygons


Rectangles And Round Rectangles


Ovals And Arcs


Friday, March 12, 2010

The Case For Raw Data And Source Code

There's been a bit of chatter about raw data and source code in science on a few of the climate blogs lately. The issue has tended to be framed as "raw data" vs "anomalies". I think that's a fairly poor way to frame it because anyone using anomalies can also use raw data, and vise versa.

Bottom line, I think it's extremely important for scientists to make all their raw data and computer source code available to the public. The rest of this post will present a few reasons why.

The Computer Is The Science
Computers increasingly play a central role in science. They don't just tabulate results and draw graphs. They are actually the tool used to perform measurements and experiments and to even define the physics used to conduct the experiments.

String Theory, for example, has very little relationship to the real world from an experimental point of view. Most of String Theory is code running on a computer. Climate models too are computer programs that define a physics and execute entirely on computer.

I'm not trying to make an argument over whether or not doing science on a computer is good or bad. I'm merely pointing out that it's done, and it's rather common.

Point 1: Verifiability
A consequence of having your physics defined by code and your universe defined by data is that the experiments run on a computer cannot be verified without the code and data. In order to have verifiability, a fundamental goal of science, the code and data must be available. I think this is obvious, but I want to present an example of unverifiable science that was just reveled on this blog.

The Aqua satellite has an instrument called an AMSU that scans the Earth detecting 15 different frequencies of light. Each of these detectors is called a channel. It turns out that the hardware for channel 4 failed in late 2007, and since that time NASA, who owns the Aqua satellite, has been producing the data from channel 4 not from readings detected by instruments, but from computer code and lookup data.

They actually have good reasons on why this should work. They've performed tests using their code and lookup data and the results match reality very well. The problem is, the code and lookup data to create this synthetic channel 4 data is not available outside NASA's JPL lab. This means that not only has no one from outside JPL ever verified their claims that the procedure is sound, no one outside JPL can verify those claims. We (no mater who "we" are) have to take it on good faith that the data NASA creates for channel 4 is realistic. It cannot be demonstrated to be realistic.

Clearly, this is not science. To get science back on the track towards verifiability in the modern world, open access to all data and computer code is needed.

Point 2: Data Compatibility
I think this second point applies more to climate science in particular than science as a whole. It has to do with the concept of processing temperature data into anomalies. There are very good reasons why scientists convert temperature readings into anomalies. If done with care, anomalies can be used to meaningfully compare two different sets of data, for example.

Anomalies also have the nice feature of tracking changes in temperature in a way that's not dependent on the temperature that came just before it. For example, a July anomaly of, say, +0.2 doesn't mean that July was +0.2 degrees hotter than the previous June. It means it was +0.2 degrees hotter than the July from the previous year. All by itself, this use of anomalies filters out unwanted noise from that data. We're not interested in learning if it gets hotter as we move into summer. We already know it usually does. We're interested in learning if the trend over the years is going up or down. And that's what anomalies tell us.

But it's difficult to compare data in anomaly form to data that's not in anomaly form. And most climate data, CO2, water vapor, sun spots, cosmic rays, etc., etc. is not in anomaly form. So if we have a July that's cooler than the previous July but warmer than the June just before it, the July anomaly goes down, where as the July temperature and most other climate data that's correlated to temperature, goes up.

Point 3: Errors
I'll make this last point quick, because this post is longer than I expected.

You simply cannot find errors in data that's been homogenized and processed until it no longer has it's original shape. Smoothing, averaging, and so on, wash away these errors and the person using the data doesn't know they were ever there. This doesn't mean, btw, that such processes correct the errors. They simply hide them. To verify that the data is correct, both the original data and the computer code used to process it is required.

Conclusion
So these are some of the reasons I believe it's important to make all data and computer code available to the public. I want to stress again that making raw data and code available is not an argument against using the processed data results and no code. There's no reason why you can't do both.

Thursday, March 11, 2010

Climate Scientist Starter Kit v2.0 Coming, Part IV: Total Solar Irradiance, Sunspots, Regional Cosmic Rays

In this post we look at several new data sets being added to version 2.0 of the Climate Scientist Starter Kit: Total Solar Irradiance (TSI), Sunspots, and regional Cosmic Rays.


Total Solar Irradiance (TSI)
Total Solar Irradiance is the amount of sunshine hitting the Earth's atmosphere at any given time. Version 2.0 of the Climate Scientist Starter Kit includes monthly TSI values taken from three satellites at three different frequencies. This data extends from February, 1996 to October, 2009.
Total Solar Irradiance (TSI)


Sunspots
Version 1.5 of the Climate Scientist Starter Kit already has Sunspot Group data. Version 2.0 adds Sunspots. This data extends from January, 1749 to January, 2010.


Sunspots


Regional Cosmic Rays
Regional Cosmic Rays have been added to the existing Cosmic Ray data of version 1.5. With this added data, there is now at least one cosmic ray measurement for every region used by UAH when it publishes temperatures: Northern Hemisphere, Southern Hemisphere, Tropics, Northern Extra Tropics, Southern Extra Tropics, North Pole, South Pole, and the 48 U.S. continental states.


Thule, Greenland (North Pole Region)


Swarthmore, Pennsylvania (U.S. 48 States, Northern Extra Tropics)


Climax, Colorado (U.S. 48 States, Northern Extra Tropics)


Haleakala, Hi (Tropics)


Hauncayo, Peru (Tropics)


Hermanus, South Africa (Southern Extra Tropics)


McMurdo, Antarctica (South Pole)


South Pole (South Pole)


McMurdo, Swarthmore, South Pole, Thule, Cosmic Rays





Previous Posts In This Series:
Climate Scientist Starter Kit v2.0 Coming
Climate Scientist Starter Kit v2.0 Coming, Part II: Regional Data
Climate Scientist Starter Kit v2.0 Coming, Part III: Ozone And Pressure

Wednesday, March 10, 2010

Note On NASA's Lack Of Limb Adjustment

I talked about limb adjustment in this post. In part of NASA's reply to my questions about their data, they noted they don't do limb adjustments to the data. Specifically, they said:
The AIRS retrieval code (statistics engine) does not incorporate a limb adjustment as you have described above. Where reliable sensor data is available, it is applied directly to the appropriate portion of the atmosphere, taking into account the angle of the observation.
So unlike NOAA who adjusts the readings to have them all at the same altitude, NASA uses the different readings at different footprints for exactly what they are: measurements at different levels of the atmosphere.

This means that I have to make sure the footprints I'm using are the footprints used by UAH. It may turn out that footprint 15 of the channel 5 data, which I used in this previous post, is not used by UAH. I may need to look further out to get the data UAH uses. So when I finally get to part two of the UAH anomaly post, I'll make sure Im using the correct footprints.

References:
AMSU Limb Adjustment
NASA Responds
Trying To Find The UAH January Anomaly In The Raw Data, Part 1 Of 2

 Previous Posts In This Series: