Heat Wave in Victoria

Update - I've extended the table of temperature extremes below
Tennis fans everywhere will know that we had a pretty torrid heat wave last week, the first week of the Australian Open. It wasn't our hottest, but it went for four days. In Melbourne max temperatures were were 42.8,41.7, 43.9 and 43.9°C, or, if you prefer,109, 107, 111, 111°F. This forecast from the BoM explains what was happening; it happened as predicted, a bit warmer at the end. MikeH in comments noted this more complete report from B0M.

There's the usual argument about AGW. WUWT doesn't think so. In fact, they won't much concede that it was hot, and say it happens all the time here. So I thought I'd review in this post our summer temperature history, and also refute some notions that it's all happened before but been hushed up by "adjustments".


Monkey Mia, WA, From ABC

Data

The Bureau of Meteorology here has online daily data which is unadjusted. It's convenient to use, but not to download. For that I used GHCN Daily files which can be found here. They are unadjusted historic temperatures, derived from (and apparently identical to) BoM. Melbourne’s file is ASN00086071.dly; it has good coverage from June 1855 to Dec 2013. I supplemented it with current online data to date.. I extracted them to a CSV file which I've placed here.

Plots

I've plotted each summer (DJF) max temperatures from 1856 to 2014 (counting by the JF year).

1860 1870 1880 1890 1900 1910 1920 1930

1940 1950 1960 1970 1980 1990 2000 2010

You can switch from year to year using the top buttons, and go to any decade year with the radio buttons.

Our summers are made up of many pleasant days, with southerly winds, with heat when the wind blows from the North. Notably hot summers were in 1908, 1939, 1983, 2009. The last three had devastating wildfires on the hottest days, which I've linked. Big heat has bad consequences here. We lose towns, homes and people.

Table of extreme temperatures

Originally, I had here a list of the twenty hottest days in Melbourne since 1855. Following a suggestion in comments by SC M, I have updated to inclide tables of the 20 highest daily max, highest min, lowest max and lowest min. I've marked those occurring in the last five years in red. For highest max, there are seven. Click the buttons.

High Max  Low Max  High Min  Low Min

Adjustments?

In the WUWT thread I encountered over and over claims that BoM had rigged the records by adjusting old readings downwards. It's very hard to get specifics (typically the complainant just gives a link, which is often to a rant about GHCN, or GISS). Eventually it crystallised to complaints about Acorn. This is a recent homogenised set of data for 112 chosen stations, starting in 1910. The lead post in fact claimed that the BoM had discarded all data before 1910, which puzzled me.

But of course the data is not discarded. All the old unadjusted data is available from BoM, and also from GHCN. And it is what the BoM uses when talking about station extreme temperatures. If you go to the Melbourne climate page, for example, it will tell you that the hottest December day was 15 December 1876. That's not Acorn.

So how do we know these are really unadjusted? I've known since boyhood that Melb reached 114.1°F on Jan 13, 1939. That's what the record still says. But I checked others. The National Library has an old Melb (and others) newspapers here. I've checked a few of the reportewd high temps; the GHCN record linked here agrees with the contemporary reports. I think it's up to claimants of adjustment to give one example from this dataset.

December GISS Temp down by 0.18°C

In my post on TempLS for December, I noted that it fell by 0.17°C from November, almost exactly cancelling the previous month's rise. GISS followed almost exactly the same sequence, down from 0.78°C to 0.6°C, having been 0.61°C in October.




And again, Russia and Siberia were very warm; N America was  cold. Here is the GISS map for Dec 2013:
Update - I had originally linked to the November plot



And here, with the same scale and color scheme, is the earlier TempLS map:

Previous Months

November
October
September
August
July
June
May
April
March
February
January
December 2012
November
October
September
August
July
June
May
April
March
February
January
December 2011
November
October
September
August 2011

More data and plots

Generic code for WebGL Earth data plotting

In a previous post, I said I would post code for WebGL data presentation, in the style of posts here, here, and here. I supply an HTML fragment which includes the JavaScript (JS) master code; you supply a file with a JS function prescribing data. Apart from opening and closing the function, the JS is just data assignment. You should see that previous post for references and basic explanation of JS, HTML5 and WebGL. I'll call the code Moygl.

With Moygl, you can draw on the Earth surface:

• POINTS - dots of various size and color
  
• LINES - a group of individual line segments
  
• TRIANGLES - each individually specified. Normally these will be filled with shading
  
• LINE_STRIP - a long list of vertices which will be connected in sequence (can be broken with NaN).
  
• LINE_LOOP, TRIANGLE_STRIP and TRIANGLE_FAN
  

I've given the WebGL names (LINES etc). The last three are just ways of reducing repetition of vertices. I stick to POINTS, TRIANGLES and LINE_STRIP. The native style of WebGL input is as a flat array, so eg TRIANGLES would have for each triangle the first 3 coords, then the second, then the third, and then the next tri. But the scheme here also allows you to point to a list. RGB colors (range 0-1) are similar but again here there is the option of a palette and pointers.

Example

I'll start with an example data file. This draws on the Earth an octahedron of shaded triangles and a cube of blue lines:
function PxDat(p){
 var Octa, Cube;
 Octa=p[1]; 
Cube=p[2]; 
Octa.type=TRIANGLES; 
Octa.nodes=[0,1,0,  1,0,0,  0,0,1,  -1,0,0,  0,0,-1,  0,-1,0] 
Octa.links=[0,1,2,0,2,3,0,3,4,0,4,1,5,4,3,5,3,2,5,2,1,5,1,4] 
Octa.palette=[0,0,0,  1,0,0,  0, 1,0,  0, 0,1,  1,1,0,  1,0,1,  0,1,1] 
Octa.cols=[1,2,3,4,5,0] 
Cube.type=LINE_STRIP; 
Cube.palette=[0,0,1];
Cube.nodes=[NaN,NaN,  40,45,  40,135,  40,-135,  40,-45,  -40,45,  -40,135,  -40,-135,  -40,-45];//lat/lon 
Cube.links=[1,2,3,4,0,5,1,4,8,0,6,5,8,7,0,3,7,6,2] 
}
The first and last lines are in every file; they define a function. The argument p is an array of objects. In JS if you assign an array or object to a variable, the variable is a pointer, not a copy. So the two objects we want are renamed (locally).

Object properties

I'll describe the properties set in this list:

• .type : You should always set this to one if the types listed above. Default is POINTS.
  
• .nodes : Every object will need a list of nodes, in 3D unit sphere coords, or by lat/lon in degrees. I've used both types here. In either case, the numbers provided are a flat list of the coordinates in node by node sequence. See next for usage.
  
• .links : Without a .links, the nodes are used in the order supplied. .links is a list of integers, starting at 0, which makes a new vertex vector selected from the nodes list. Nodes can be used several times, or not at all.
  
• .palette : This is the specification of RGB colors, range 0-1. Like nodes, the triples are listed in a long sequence. There is an analogous sequence of pointers (.cols, see next), but here it is obligatory, unless the palette has only one color, in which case it is applied uniformly.
  
• .cols : A sequence of vertex colors, being integer pointers into the palette. There should be one entry corresponding to each node in .nodes. In GL triangles, the node colors are used to give shading by interpolation. If you want color discontinuity, you can enter the same point more than once into .nodes, and give it different colors.

Those are the important properties, and the ones used in the example. Here are some others you might need:

• .size : Used with POINTS objects to set the size, in pixels. No effect on other types.
  
• .alt : In GL, only the front pixels are seen. .alt lets you raise the object nodes above the surface of the unit sphere (alt=0) to improve visibility, It should rarely be needed,
  
• .tags : There is a facility whereby left clicking on the globe locates the nearest node of a POINTS object with this property. The tag is printed top left. So .tags is an array of HTML strings (quotes, commas), one for each entry in the .nodes of that object (no need for .links).
  
• .scale : This allows you to attach a color scale to a shaded plot. It is a vector of labels (strings or numbers, they can be mixed). A color bar will be placed bottom right showing the range in the palette, and the labels will be placed at equal intervals. You need at least two - one for top and one for bottom. It only makes sense to provide this property for one object.
  

Drawing issues

POINTS are drawn with size defined in pixels by ,size (default 3). Lines are drawn width 1 (no choice), in segments approximating a great circle. Triangles are drawn plane, with shading. There is a pale blue disc (object 0, built-in) which separates the seen hemisphere from the unseen. It means you don't see points and lines from the other side.

Usage

Update - I've made a change to the file arrangements here. There are now 2 files Moygl.html and Moygl.js. The html file is short and ends with the call to the data file and to Moygl.js. It's that data file call where you insert your own address.

If you look at about line 8 of Moygl.html, you'll see
<script type="text/javascript" src="octa.js">
</script> octa.js is the above data file. You can replace with your file given by relative addressing, or an absolute URL.Then you just paste Moygl.html into your own HTML, and display in a browser. Moygl includes a HTML table structure that you can modify. The sphere that appears is a trackball. You can rotate it with the left mouse button, or zoom with the right (up is bigger).
As said about, if there is a .tags, clicking will show the nearest tag top right. Free rotation is a mixed blessing; it takes a while to sort out messed up orientation. Clicking the orient button, top right, rotates the visible hemisphere till N is up at the centre.

Examples displayed.

Here is the octa/cube example from above, displayed:

 

It shows how the lines forming the cube are almost great circle segments, while the triangles are plane. This is less problematic for real shading applications where the triangles will be much smaller. 

Here is an example showing more features. It is derived from the recent "Just 60" post, which uses a triangle mesh to cover the Earth and derived a station-centred tessellation. Since this is just a graphics illustration, I have started using all GHCN land stations with 50 years data and refined to get reasonably uniform coverage. The points reprsent the stations, the lines the area subdivision, and the shading is by latitude. I chose this to show the merits and deficiencies of the shading for a known variable - I think it is quite good for a coarse mesh. But effects are visible especially where big triangles are at the edge of the disc.

 Extra features included are tags - you can click for station names - and the color key. I'll show below how the data file looks.

 


This time the numerical data is bulky. I have truncated the long lines:
function PxDat(p){ 
var Tess, Stats, Mesh, Map; 
Tess=p[1]; 
Stats=p[2]; 
Mesh=p[3]; 
Map=p[4]; 
Tess.type=Map.type=LINE_STRIP; 
Stats.type=POINTS; 
Mesh.type=TRIANGLES; 

Stats.palette=[0,.1,0]; 
Stats.size=3; 
Stats.nodes=[0.0967,0.6008,-0.7935,0.0145,0.5563,-0.8309, 
Stats.tags=[" SKIKDA"," GERYVILLE ALGERIA "," ADRAR ", 
Tess.palette=[1,0,0]; 
Tess.nodes=[NaN,NaN,NaN,-0.4178,-0.6069,-0.6761,-0.4763, 
Tess.links=[727,729,728,955,1180,1179,727,0,165,418,954,
 Map.palette=[.5,.5,.5]; 
Map.nodes=[55.9217,-130.005,55.9117,-130.0131,NaN,NaN,52.8378, 
Mesh.links=[76,325,296,305,624,559,299,305,559,542,299,559, 
Mesh.nodes=[0.0967,0.6008,-0.7935,0.0145,0.5563,-0.8309, 
Mesh.palette=[1,0,0,1,0.0196,0,1,0.0392,0,1,0.0549,0,1,
 Mesh.cols=[205,199,188,187,187,181,178,108,94,142,84,78, 
Mesh.scale=["-90",-45,"0",45,"90"]
 }
The complete Moygl HTML/JS code and example data files are on this zipfile.

Using WebGL for Earth data mapping.

I have been using WebGL for some time for presenting shaded plots and other information on the Earth's surface. Examples are here, here, and here. Merits of WebGL include:

• Dynamic tracking. You can drag the sphere plot to any orientation and magnification, as with Google Earth.
  
• Good and convenient shading for continuous fields
• Integrated with Javascript and HTML5 canvas.

I had said that I would say something about my experience with WebGL. I have been writing a generic program to do a world plot from input data files, which I hope to blog about. Here I will describe just what are the essentials of writing a WebGL program for these relatively simple circumstances.

  WebGL is an version of OpenGL, where programming is done in Javascript embedded in a HTML file and implemented by the browser. Reference material for OpenGL mostly comes from the Khronos Group, eg here, here, and here. Specifically for WebGL, there is a handy reference card. various people provide online tutorials; I've benefitted from Greggman and this site (link is to a "simple" program which does indeed display the minimal requirements).

The best place to find out about the HTML and Javascript (JS) facilities I use is W3C Schools. It has an environment where you can try out and modify code fragments for all kinds of commands and objects.

Writing a Javascript program

Javascript is like C, but with no i/o. So numerical data is entered as part of the code. JS is embedded in a HTML file between <script></script> tags. Links are made by assigning id's to HTML elements, and also call-backs (eg onclick="fn()"). fn() will typically be a JS function. JS can identify the elements by id, and modify them.

Script tags can link to an external source. JS can modify the original page; after it has appeared, it goes into listening mode, driven by events like mouse clicks.

 When developing a JS program, I usually place it in a file with minimal html, and show it in Firefox, with the free Firebug debugger add-on engaged. Then I can step through the code with all variables displayed in object hierarchy style.

 The JS program you write is downloaded and run on other peoples' computers, so there are security limitations. All code and data has to be readable by the user. You can't access file spaces, or even other windows - this can be a nuisance when embedding frames.

HTML 5 and WebGL

HTML 5 introduced new drawing facilities, particularly SVG and the canvas. A canvas is a HTML element, specifying an area of screen, and with a context offering JS functions etc that allow you to control drawing in the space. The common context is "2d", which I used extensively in the climate plotter. "webgl" is an alternative context, now offerred by most browsers.

 As said above, WebGL is based on OpenGL, which is in turn derived from the Silicon Graphics Iris GL of the 1990's. That was considered 3D graphics, but as Greggman maintains, WebGL is also a 2d context. It is capable of very rapidly implementing the 3D geometry transforms, but you have to write them. However, it supports the OpenGL ES shading language which makes this easy.

Structure of a WebGL App

You need to create a master object called a program. There can be several. To each you need to attach a vertex and a fragment shader. These are the little programs written in OpenGL ES that will be passed to the GPU. I usually write them (with JS help) as strings, which are compiled and attached.
The vertex shader typically specifies a 3D transform to the original vertex data, expressing user-induced motions. You may also link color information to the vertices.

The fragment shader tells what to do between vertices; it may reduce to just a color specification. 

Much of the rest of the program is concerned with putting the geometry data in buffers for GPU access, and connecting the names to the names in the shaders. When that is all done, you give a draw command - I use DrawArrays. At this stage you specify a shape (for which the buffers were designed). Options are POINTS, LINES, TRIANGLES, LINE_STRIP, TRIANGLE_STRIP, LINE_LOOP and TRIANGLE_FAN. In the first three, you just specify each item with all coordinates in full. That's bulky, so the remaining are ways of writing larger structures mitigating writing out the same coords several times. The shapes then appear (you can flush).

WebGL also has provision for perspective, lighting, texture etc, which go into the shaders. For presenting numerical plots, as I do, these aren't needed.

I linked above a minimal program. It doesn't do much, but shows the basic requirements.

Applications and a generic program.

At the start of this post I linked some Moyhu WebGL programs. The common theme is the display with points, lines or shading, of data on a spherical Earth that can be rotated or zoomed. I've written a program which formalises this, with data supplied in standard JS structures. I'll post about this soon.

TempLS global temp down 0.17°C in December

The TempLS monthly anomaly for February 2013 was 0.417°C, down slightly from 0.433° in January. I had earlier calculated a rather larger drop, but more incoming data have reduced that. It's still rather early, but there are 3832 data points, which is quite a good number.

This contrasts with very large drops in the satellite indices. But again, they had risen much more in the previous month.

Here is the spherical harmonics plot of the temperature distribution:



And here is the map of stations reporting:

Just 60 global stations - area weighting shown with GL graphics.

Twice before I've written about using just 60 met stations to estimate the Earth's global temperature anomaly. The first time I simply chose 61 stations according to "quality" criteria (rural, 90 years records). The resulting average was quite close to HADCRUt land only and the GISS met stations index. This was somewhat surprising, because the stations were in effect not area-weighted, but sin(latitude) weighted.

Then I wrote about trying to get proper area weighting using triangular meshing. In doing that, I used sequential meshes to try to get more even distribution. That post came just before my recent interest in better graphics, and I could not then present the mesh results properly. I can now. The temperature analysis there still stands, and is not developed in this post, but hopefully soon.

It is worth reviewing the motivation. The first post was a response to a challenge by Eric Santer, who thought that 60 stations should be enough for a good global average. I thought so too, but there is more to it. I'm in fact doing a version of the GISS Met stations only index, which is different from land-only in that the stations are weighted by global surface area, so ocean areas are represented by land stations. Compared with land/ocean, which uses SST, this has the plus that it measures the same thing everywhere (air temp 1.5 m above surface), and the met stations have a rich and explicit history. The minus is that the data for ocean areas is far sparser than SST.

When a large area (oceans) is sparsely covered, there is little benefit to the average in having part of the land area densely covered. It makes sense to select a subset of stations, trading density for quality. If the subset can be reduced to 60, say, then the individual stations can be more closely scrutinised. "Quality" here is a combination of long records and apparent freedom from biases like UHI (rural stations).

We want stations of quality that are also fairly evenly distributed - ie have approx equal area weighting. This post does that by compromising initially on quality to get a larger subset, and then in several steps remeshing, eliminating stations of least weight. This is shown by a display of the area attributed to each station at each stage of reduction. The display is in WebGL, which means you can rotate the Earth track-ball style. It also shows a histogram of weights, and lets you click to see the station names.

The plot

Initially, 622 stations are shown. These are GHCN stations classified rural, with at least 50 years of record continuing to at least 2010. Then at each of six stages, the bottom third of area weighted stations are removed, and the remainder remeshed. The radio buttons show the result.

The area assigned to each station is formed by connecting the circumcentres of each of the mesh triangles. Each area is the set of points where that station is the nearest node. See below for some details here. The plot shows the area and the station with a purple triangle. You can click near this to show the station name top left. Bottom right is a histogram of the area weights.

Update - there is a glitch. There are two plots below, and only one can be active (for trackball etc) at a time. That is determined by which was last selected (by radio button).

Quality specs Rural at least 50 years Some data since 2009 Number stations 622 422 286 194 132 89 60

Details

The circumcentres are not exactly the plane centres, because they are projected onto the sphere. The lines are made of two sections, with the midpoint apso projected onto the sphere. This makes them a little more like great circles.

In fact the weight is not quite area. It is for each triangle the volume of the tetrahedron formed by the triangle and earth centre. This is area (triangle) times height, which is very close to the earth radius.

You might expect the areas under the histograms to be much the same, while they seem to increase with subdivision. The reason is that the y-axis varies, but I wanted to keep the same plot size and the same x-axis.

Clicking to show station names only works for the plot where you last clicked a radio button.

Alternatives

A merit of this approach is that a small change can generate a substantially different mesh. So one can test how much the average depends on the specific mesh. That's the next project.

In the plot below, I specify a higher quality spec (70 years of data). That means fewer stages of subdivision, so the penalty is less even weighting. The initial disparity is such that the subdivision only affects part of the Earth, as you can see.

Quality specs Rural at least 70 years Some data since 2009 Number stations 404 278 188 129 88 60