One, which I'll continue to defer for now, is the fact Arthur mentioned that what this model works with is the earth's blackbody temperature -- its temperature as seen by how much energy it releases to space -- rather than surface temperature. Since we all live somewhere towards the surface, surface temperature is the more interesting number. What the difference between what the model can give us and what we're truly interested in does is to suggest that an important theoretical issue is to develop an understanding of how planetary blackbody temperature relates to surface temperature. Or (scarier) to see

*if*it does relate in any consistent way. But heads up that such a discussion will be coming. Finding these issues, and seeing why they're important, is one of the purposes of the ultra simple models like this.

More issues were brought up by Nick Barnes, who also provides Python code for running your own version (see his first comment for that link). I hope you've spent some time with either the spreadsheet or Nick's Python (use a 2.7 set-up, per Nick's comment on Tuesday) or do so now, as you read this post, and some more as you decide whether and how it makes sense. The spreadsheet is in OpenOffice format (.ods) but I've opened that with MS Excel previously. If you can't, please let me know.

Now, in saying 'issues', I don't mean that there's any terrible comment being made. Rather, it is the truth that even very simple models like this one have some subtleties that you should explore before drawing your conclusions about nature. I'll take up the more physical side of interpretation next, but first let's take a look at some of the technical issues.

One thing is, the standard deviation in the model (which tells us how fast albedo changes with temperature) doesn't change what answer we head towards, at least not if 'rate' is a small number. Experiment with this, don't take my word. In terms of the modelled planetary temperature, then, what it tells us is important is not the detailed structure of the function of albedo versus temperature, but the value of albedo at the extremes.

Second, the first guess temperature

*does*matter -- if it's below a certain number (255 K) we get the cold solution, and if it's above, we get the warm solution. There's an unfortunate coincidence in my choice of numbers in the original model. Namely, an albedo of 0.3 (the minimum albedo in the model) produces a temperature of 255 K. But 255 K is also chosen to be the temperature at which the minimum albedo occurs. Try changing the 255 (T0) to some other number, say 245. What number is important to this business of dividing solutions to the cold or warm side? Is it T0, or the temperature at minimum albedo, both, neither? [Seriously, do the experiment. One route is to leave the albedo alone, which I recommend, and then change T0. Then make an x-y plot of your results. More elaborate is to change both albedo and T0 and make a shaded or contour plot of your final solutions.] Typical business -- after starting with an experiment, we see that there is more to experiment on, even in a model as simple as this.

Third, 'rate', which Nick Barnes questioned my reasons for having used such a small value, is necessary partly because of numerical analysis. Namely, computers don't do math the way we're taught in elementary school and high school. For instance, A + 1.0 can equal A, which in algebra by pencil is impossible -- it would require 1 = 0. (Try it; no problem for A = 1 or 10, but let A = 10,000,000 or 10,000,000,000 and see what happens.) Related numerical analysis concerns are part of why he'll (and you will) see different solutions in Python on his computer than I will in a spreadsheet on mine.

Also try the experiment of changing 'rate' from 1 to things that are very tiny but not zero. I used 0.01 most of the time, but you should be able to go as small as 0.0001 and still get usable answers even in the spreadsheet. Plot the answer you get against the value of 'rate' you try. For now, I'll just note that these issues in solving implicit equations are well-known to people writing climate models.

A different point about these considerations. At some point in a modeller's history, they need to spend some time learning how many ways they can fail to get the right answer on a computer, for reasons other than programming error. One of mine was discovering that 100,000 + 1 did not equal 100,001 on a certain computer. On that one, it equalled something like -34,465. After that experience, I got much more skeptical/careful about computer arithmetic.

## 10 comments:

I've never used Python before (as I stated in the previous thread, I believe).

So based on this thread I've installed 2.7.2 from the Python site.

Also downloaded the PDF documentation for 2.7.2

When I download simplest.ods it wants to save it as simplest.zip, which appears to be the bits and pieces (mostly appears to be XML code) code) to make the simplest2.ods spreadsheet file.

But if I save it as simplest2.ods, than the spreadsheet itself emerges, but all numbers are "static".

I've also downloaded Nick Barnes albedo.py file. Double clicking on that file briely opens/closes a CLI window

Like I stated at the beginning, I have no Python experience at all. Don't know where to install the albedo.py, simplest2.zip and/or simplest.ods files. And don't know how to execute and/or change the code to generate a new simplest.ods file.

Now what was the point of all this again?

I mean, I guess I assumed that the simplest climate model would be rather simple to use.

Like a simple Excel spreadsheet with "dynamic" cell references (changable cells from the preameter list section).

I'a actually quite good at Excal, but don't know diddly about Python.

Sorry, but without further help, I'll just have to leave the Python basrs simplest climate model to Python programmers. Which meand that, in fact, the simplest climate model, may be just that, given that one is an experienced Python programmer. To all other peopls the label simplest climate model is a bit of an oxymoron IMHO.

If you really want it to be the simplest climate model, it does not get much simpler than an Excel spreadsheet with "dynamic" cells.

Perhaps if I installed Open Office the simplest2.ods spreadsheet would look different (e. g. with dynamic cells)?

In closing, to date, two articles, but virtually no understanding of how to use the simplest climate model, at my end, from what has been stated to date.

Sorry, but I'm moving on.

Object lesson? KISS.

Hi Bob,

I have the same question as above. Do I need Open Office to get a working spreadsheet. Perhaps there's a way to import into Excel without losing the formulae? I will be sticking around, as other lessons you've provided have been worth the wait.

jg

Hi,

You can download Openoffice for free from here:

http://openoffice.filewin.net/?p=UK&gclid=CKnu16PmhK8CFZARfAodMynq1A

Cheers, Alastair.

I'm puzzled by the difficulty people have had with the spreadsheet. One issue, perhaps, is that the original seems to open automatically to sheet 2, rather than 1. On 2, I was looking at some other things. But on going to 1, all equations were present as I expected them to be. Also the open document vs. excel issue. Don't know how/why that surfaced.

I've resaved the sheet so that it only has the first page and verified that it opens automatically to that from a download. Try http://www.radix.net/~bobg/blogsupport/simplest2.ods

I've also saved it as Excel format (XP version, as written by openoffice), http://www.radix.net/~bobg/blogsupport/simplest2.xls

Please let me know if these work for you (all)!

Thanks Alastair for the link and Bob for the Excel. Bob, your latest Excel spreadsheet is different from what I got when I imported the ods file. (I did try the import a couple times and I did examine both sheets within the file too.) So, I have the working file now and experiment with it later today.

I have discovered that when you open the files they are in read only mode. The .ods version has to be saved on your computer before any changes can be made.

Cheers, Alastair.

More better Python code, and more illustrations, here. Probably not a great introduction to Python, but anyone who really wants to give it a go should first install the Enthought Python Distribution and learn how to use the iPython notebook (started with the command "ipython notebook --pylab inline").

The real problem with this model is that the root-finding algorithm is slow (may take a very large number of iterations to find a root, specifically the cold root, because the derivative of the expected albedo is close to zero there) and unstable (may not find local roots, specifically the warm root(s), because the rate step can leap over them). There are better root-finding algorithms, but the underlying problem is ill-conditioned: the warm roots (with the default Gaussian albedo) are so touch-and-go that if the parameters are even slightly different (e.g. min_albedo=0.302, or T_central=256) then those roots disappear altogether, and only the cold root exists.

Regarding your comments on computer arithmetic: it is certainly the case that anyone using a computer to do sums should educate themselves about the numerical systems used by their computer. They aren't very complicated, and their behaviours are generally very well-specified. But even among scientists one can encounter a kind of cargo-cult approach to floating-point sums.

Did my other comment on this post get lost in the spam filter? It was some thoughts on a slightly more physical model (in which the Earth has a heat capacity, and the radiative imbalance causes the temperature change).

Just for reference, here is a really basic excel EBM.

http://cires.colorado.edu/steffen/classes/geog5211/1-D_EBM.html

Post a Comment