Is the NULL default infinite hot?
January 31, 2010 by E.M.Smith
see his website “Musings from the Chiefio”
The empty ocean goes infinite hot on a null anomaly
What to make of THIS bizarre anomaly map?
What Have I Done?
I was exploring another example of The Bolivia Effect where an empty area became quite “hot” when the data were missing (Panama, posting soon) and that led to another couple of changed baselines that led to more ‘interesting red’ (1980 vs 1951-1980 baseline). I’m doing these examinations with a 250 km ’spread’ as that tells me more about where the thermometers are located. The above graph, if done instead with a 1200 km spread or smoothing, has the white spread out to sea 1200 km with smaller infinite red blobs in the middles of the oceans.
I thought it would be ‘interesting’ to step through parts of the baseline bit by bit to find out where it was “hot” and “cold”. (Thinking of breaking it into decades…. still to be tried…) When I thought:
Well, you always need a baseline benchmark, even if you are ‘benchmarking the baseline’, so why not start with the “NULL” case of baseline equal to report period? It ought to be a simple all white land area with grey oceans for missing data.
Well, I was “A bit surprised” when I got a blood red ocean everywhere on the planet.
You can try it yourself at the NASA / GISS web site map making page.
In all fairness, the land does stay white (no anomaly against itself) and that’s a very good thing. But that Ocean!
ALL the ocean area with no data goes blood red and the scale shows it to be up to ‘9999′ degrees C of anomaly.
“Houston, I think you have a problem”…
Why Don’t I Look In The Code
Well, the code NASA GISS publishes and says is what they run, is not this code that they are running.
Yes, they are not publishing the real code. In the real code running on the GISS web page to make these anomaly maps, you can change the baseline and you can change the “spread” of each cell. (Thus the web page that lets you make these “what if” anomaly maps). In the code they publish, the “reach” of that spread is hard coded at 1200 km and the baseline period is hard coded at 1951-1980.
So I simply can not do any debugging on this issue, because the code that produces these maps is not available.
But what I can say is pretty simple:
If a map with no areas of unusual warmth (by definition with the baseline = report period) has this happen; something is wrong.
I’d further speculate that that something could easily be what causes The Bolivia Effect where areas that are lacking in current data get rosy red blobs. Just done on a spectacular scale.
Further, I’d speculate that this might go a long way toward explaining the perpetual bright red in the Arctic (where there are no thermometers so no thermometer data). This “anomaly map” includes the HadCRUT SST anomaly map for ocean temperatures. The striking thing about this one is that those two bands of red at each pole sure look a lot like the ‘persistent polar warming’ we’ve been told to be so worried about. One can only wonder if there is some “bleed through” of these hypothetical warm spots when the ‘null data’ cells are averaged in with the ‘real data cells’ when making non-edge case maps. But without the code, it can only be a wonder:
With 250 km ‘spread’ and HadCRUT SST anomalies we get bright red poles
The default 1200 km present date map for comparison:
GIS Anomaly Map for November 2009
I’m surprised nobody ever tried this particular ‘limit case’ before. Then again, experienced software developers know to test the ‘limit cases’ even if they do seem bizarre, since that’s where the most bugs live. And this sure looks like a bug to me.
A very hot bug…
Discover more from Watts Up With That?
Subscribe to get the latest posts sent to your email.
There’s an announcement at CCC related to this:
Science advances in odd ways.
Score another victory for open source!
Has anyone suspected a “ghost in the machine”?????? Like Hitler’s ghost. I have see many movies where Hitler is in one of his rages going “9999”. Any correlation?????
This is serious!!!
George says:
No.
Firstly, this software is old, but not really ancient. Most of it was written in the 1980s or early 1990s.
Secondly, this software was written by scientists, not by professional programmers. This is the sort of software that scientists write. That does not make them incompetents.
Thirdly, in most scientific datasets, whether or not they are produced by software written by professional programmers, you will find missing data identified by specific in-band values, often as +/-10^n -10^m (that is, numbers such as 9999, 999.9, -9.999, 0.99999, etc). It’s just the way it is done in that field. It has various advantages, including simple and compact file formats and the ability to read in a huge array of floats in one line of Fortran. It’s a tradition going back several decades, to really ancient software.
In ccc-gistemp, we have a notion to switch eventually from the current missing data values (for which we follow the Fortran in using the variable name BAD) to an IEEE floating-point error value, possibly a non-signalling NaN value. This will allow us to retain the advantages of using a single-typed array while also getting the infectious properties of NaNs (any operation with a Nan operand yields a NaN result).
Any of E.M.Smith’s software war stories, I can match. That’s what you get for working on compiler and runtime projects for years. The garbage collector bugs were the worst (and were, specifically, my job to fix).
Lastly, I’d like to reiterate the standing invitation to any programmer who wants to actually contribute, rather than simply sniping, to come over to the ccc-gistemp project and write some code.
Incidentally, the do_GISS_analysis driver script, available from the GISS website, answers the Sooper Sekrit Mystery about where the 250-km data comes from:
# do the gridding
cd ../../STEP3
do_comb_step3.sh 250
do_comb_step3.sh 1200
That was hard.
The graphics, I think, are produced by NCAR graphics. Probably driven by the STEP6 code, which I haven’t looked at (because none of these maps are actual science products).
The most basic task regarding that dear selled GISS project does not consist in engaging a bunch of (unpayed) volunteers, mandated to shift Dr. Hansen’s convoluted code base from a typed language like Fortran to an interpreted and essentially untyped one like Python, but in putting up a well designed database of raw temperatures, which also provides station meta-data and a detailed history record for each and every imported value, much like it is standard for databases supporting security, medical, pharmaceutical, financial or forensic applications.
Regarding your CCC project, I see that even Python may be used to parse flat files. While this is a rather small step for the average programmer, it may be considered to be a big step by everyone else. However, in what respect is it appropriate to eulogize such a filiopietistic effort as “another victory for open source!”? The absolute progress here is more like Lenin once summarized the attitude of the Menshevik fraction: one step forward, two steps back.
You might like to work more on sentence construction and less on ten-shilling words. If you think ccc-gistemp is filiopietistic, you either don’t understand the project or don’t know the meaning of the term.
Which “dear selled GISS project”? Glory? ISCCP? What? “dear selled” how?
Your first sentence boils down to “The most basic task … consists in putting up a database of raw temperatures ….” Fine. If you think that is important, you go ahead and do it. I would have thought that was rather outside the GISS remit, and more a job for organisations like NOAA and the WMO, both of whom seem to do a reasonable job.
For myself, I think that GISTEMP is important, because of the prominence of its results, and latterly of the code itself, in the public discourse. I also think that code clarity is important. So that’s what I choose to work on, together with the people who have joined the project. If you don’t think GISTEMP is important, why are you commenting on this thread?
aMINO aCIDS iN mETEORITES (16:32:15) :
My post directly addressed what you want to get at. Using existing data, just run an analysis of stations that were dropped, vs the ones that were not. Zeke Hausfether’s already done a preliminary version of that, just without spatial averaging. But even then, it looks like the dropped stations behave just as the not-dropped ones.
As for Hansen dropping things: he isn’t. GISS takes the station data from the NOAA, who get it from the from the individual countries. Stations only appear to drop off because those stations aren’t continuously reported by the individual countries in the monthly format.
Patrick Davis (16:48:23) :
This doesn’t make sense. For an individual station, I could pick any baseline I wanted, and I’d still get the same trend at that station.
EM Smith:
You have used a lot of verbiage here, but I still see no response to rbroberg’s question:
“But I haven’t seen you yet disclaim or any in way moderate your position that the ‘display bug’ was ‘bleeding through to the “real data.”‘
Do you still hold that view?”
You were suspicious of any and all red splotches on the maps, especially the ones around the Arctic. With a minimum investment of time, both rbroberg and I found the specific stations that resulted in those red splotches. So it’s quite clear to us that those red spots are due to actual stations, not any grid point using a 9999 in its calculation. Do you have a reply to that?
carrot eater (09:40:49) : Do you have a reply to that?
Yes: You don’t seem to read very well.
I’ve clearly stated it was a suspicion, an early ‘line of investigation’ of a bug. NOT a conclusion. You seem to have trouble figuring that out. Not my problem. I’ve also stated that now, with the further information given, it looks more like a graphing issue: but the numbers do get used in the calculation of the average anomaly in the upper right corner, so we don’t know were else they might be used. There really isn’t anything I can do to make that more clear to you.
And I’ve also said that you never fully remove a suspicion from from the debugging list until the code is patched and that fixes the problem. (NOT just blocking the test case as NASA has done. Doing that just assures we will never know when it is fixed.) All you do is change the weighting on the probability. It is simply not possible to know what the bug is from the outside; or even by inspection of the code (since there can be compiler bugs). So until you patch what you think is wrong and run the QA suite AND it comes up clean, all suspicions stay on the ‘things to check’ list. (Heck, even after that they go into the QA suit to keep checking for those suspected error cases forever. That’s what a QA suit is all about: checking what you suspect might happen even when you believe it is not happening; because some times it does happen.)
Further, we don’t know the limits that tickle this particular bug. So any samples of individual maps that are shown valid DO NOT prove that all data on all maps are valid. If the bug can be shown localized to the graphics display, then you can start to have confidence in the numbers, but until that happens it is simply not possible to know what happens to the 9999 data in all cases. The idea that “one valid result validates the code” is broken reasoning. The same kind of broken reasoning shown in the “Harry Readme” file when they “fix the code” by taking a bad value out of the input data instead of preventing a float overflow in the first place. (I showed how to fix it properly on my site). On the next bad data item they will have a float overflow again. Similarly here. We don’t know what’s wrong, so we can’t know when it’s fixed or what it impacts. We can only hope that the guys at GISS do find the problem and fix it; and not just paper over it by preventing the test case. IFF we could run the “baseline against self” test and have a grey / white map; then we would know their fix worked. With no test case, we will be left with perpetual doubt that they have ever fixed anything. And “hope” is not a debugging strategy nor a QA suite.
You seem to want to leap to the conclusion that everything is just perfect. So go ahead. Just don’t expect me to follow you off that cliff of conclusion.
“Hammy (10:50:06) :
Has anyone suspected a “ghost in the machine”?????? Like Hitler’s ghost. I have see many movies where Hitler is in one of his rages going “9999″.”
Ahem. “9” – nine – sounds like the german word “Nein” meaning “No”. No numerology here.
Surely the “fact” table that is to be presented to the rendering tool shouldn’t contain any rows where the measure value carries either a null or a null susbstitute. Nor any rows where an identifying attribute needed by the rendering logic is null or carrying a null substitute.
If the rendering engine accepts manual input the same should be appllied by the input code, in addition there should be some range limits on input (e.g. start with -273.1C <= temperature <= 100 C as the initial ballpark for air and sea temperatures then hone it down by experience…)