Thursday, August 12, 2010

Warming trends in the Himalaya

Willis Eschenbach at WUWT once again found something that he couldn't believe. The Himalayas are warming rapidly. There's an IPCC claim that warming in lower areas of Nepal may be about 0.4 C/dec, and in higher areas 0.9 C/decade.

Willis' post got sidetracked into fussing about GISS adjustments to 20 years of data at Katmandu. But a comment on the thread was right to the point. The IPCC was relying on a paper by Shrestha et al which had looked through records of 49 stations in Nepal in finding that result.

Zeke Hausfather at the Blackboard looked at GSOD data. This is a more plentiful data set derived from SYNOP forms. It is unadjusted, but does not go as far back in time. He found there was also a strong warming trend. His analysis was based mainly on Katmandu. He also pointed out that the IPCC did not use GISS adjusted data.

So I thought I could use TempLS and the GSOD database to look at Nepal and even beyond in the Himalaya. TempLS also allows us to look at different altitude ranges, subject to station availability. Willis found only one GHCN station in Nepal - GSOD has 12, but some with short histories. Anyway, here's the analysis. Most of the trends are since 1979; data histories get sparse before then.

Update: Zeke pointed out a bug. My first diagnosis (below) was wrong. The problem was not in the analysis program but in the GSOD datafile, as modified by my preprocessor. The GSOD database is not as tidy as GHCN, and some data refer to stations not in the inventory. In the process of fixing that, a block of stations (including Nepal) got displaced by 1. This doesn't affect the analysis, but does affect the selection - you don't get the right stations. For countries, the effect is small because they are consecutive, so only one station is wrongly chosen. But for an altitude spec, it's more serious.

The Nepal trends are little changed, and Himalaya increase a bit. The two Hi sets just have too many gaps for an analysis to work, so I've dropped them.

Earlier update. Zeke, in the comments has pointed out a bug. It seems to be in the new multi-run capability of ver 2, and to affect small datasets where sometimes no information at all exists in a particular month. So the HiNepal results are invalid, and I'm checking HiHimal. I believe the Nepal and Himalaya results are unaffected.

First, an overview of the region in Google Earth, using the KMZ files described here. The rural stations are green, urban yellow, small towns brown, and the big pushpins have 50 years data recorded (very small <20 years). The sparsest section is actually India.



The first analysis is just the country Nepal. Here are the stations (numbers and maps) and plots:


The next analysis is of the Himalayas generally, defined as anywhere in Nepal, India or Pakistan N of a line given by 14*Lat+8*lon>1046 and above 1000m. For those interested in working TempLS, the specifying expression is:
mask=expression({a=tv$country;(a==217 | a==219 | a==207) & tv$alt>1000 & 14*tv$lat+8*tv$lon>1046});


Finally, here is the collected table of trends (C/decade) since 1980 and since 1990:


Here is the earlier set of trends, which used the incorrect input data:


Being able to analyse various selected subsets means that we get a feel for how regional variations might affect the conclusion that the area is warming. All these subsets show it to a marked degree. No sub-region has a rate less than 0.5 C/decade (5 deg/century).

Update. Here is a list of the stations in the Himalaya set with some metadata.
urban: A=rural, C=urban, B=small town
country: 207=India 217=Nepal 219=Pakistan
length: Number of years with atleast one month record

Namecountryaltstartyrendyrlength yrsurbanlatlon
SRINAGAR 20715871973201038C34.0874.83
SHIMLA 2072202197319731C31.177.17
KULLU MANALI 2071089200520051A31.8877.18
DADELDHURA 2171865197820018A29.380.58
JUMLA 21723001990200110A29.2882.17
KATHMANDU AIRPORT 21713371976201035C27.785.37
SYANGBOCHE 2173700197619794A27.8286.72
OKHALDHUNGA 21717201976200112A27.386.5
TAPLEJUNG 21717321978200111A27.3587.67
DHANKUTA 21712101976200832A26.9887.35
GUPIS 2192156200620094A36.1773.4
CHITRAL 21915001973201022A35.8571.83
DIR 21913701980201012A35.271.85
DROSH 21914651957201042A35.5771.78
GILGIT 21914591973200911B35.9274.33
SKARDU 21921811975200913A35.375.68
BUNJI 2191470200520095A35.6774.63
CHILLAS 2191251200520095A35.4274.1
ASTORE 2192168200520095A35.3774.9
CHITRAL 2191500200520051A35.8871.8
BATTAL 2191676197519762A34.5873.15
KAKUL 21913091973201019C34.1873.25
CHERAT 2191372200520095A33.8271.88
MURREE 21921271973201015C33.9273.38


  1. Nick,

    If your high Nepal series is only based on stations SYANGBOCHE and JUMLA, where are you getting all those years of temps? The stations only cover 4 and 10 years respectively, and none of the other Nepalese stations are over 2000m.

  2. Zeke, that is a puzzle. I think the fault is likely to be in the table I added at the bottom, because the station count says that there was at least one station reporting throughout. I'll check.

  3. Nick,

    If my reading of the data is correct, only Kathmandu Airport has a particularly complete record post-2000. It seems to dominate any GSOD-based reconstructions of Nepalese temps due to the rapid rise from 1995-present. Perhaps its somehow creeping into your high elevation series?

  4. Zeke,
    I think you're right. I'm using V2, as yet un-released, and it has a new multi-run capability. It looks like it doesn't properly clear data between runs. If I do HiNepal first, the run fails, as it should.

  5. Zeke,
    an update. I think the Nepal and Himalaya results are OK (but still checking). Th effect of the bug seems to be that when there's new data, it overwrites the old data from the previous run. But if there's no data at all, the data from the previous run stays. So it only affects datasets where all stations have a simultaneous gap - ie fairly small ones like HiNepal.

  6. I need to make sure that users of my GSOD data realize that it is "filtered" by those stations for which I could construct a unique psuedo-"cc+wmoid+rec" and by those which could pass through GISTEMP STEPS 0,1,2,3. Recall that I was interested in creating an alternate data set for use with GISTEMP.

    On my next pass through GSOD, I will be providing two files, one 'raw' and one 'psuedo-ghcn, gistemp-ready'

  7. Nick
    The drop in station count may be related to Nepal's civil war.
    These temperature records may also have some unusual “anthropogenic” influences due to Nepal’s civil war.

    Unrest reached Kathmandu in 2004 when the Maoists announced a blockade of the capital city. Intense fighting and civic unrest continued well into 2005, with the death toll rising to 200 in December 2004. On 1 February 2005, . . . King Gyanendra assumed total control of the government.

    These events influenced tourism and thus airport arrivals/departures. Nepal dropped from 10th to 27th most popular destination. The civil unrest may also have affected manual temperature recordings!

    It would help to have ground validation from skeptics familiar with each site before putting too much confidence in some of the data, especially in regions of "unrest", particularly in western regions outside of Kathmandu.

  8. Nick
    Regarding your Nepal station count and offset, suggest checking for altitude bias and rural/urban in the station data. Nepal's civil war may have contributed to dropping out more of the western, remote, and higher elevation sites, leaving larger lower urban areas. This might give a warming bias to the remaining data.

  9. David,
    There's nothing much that can be done about that. But there's no reason to think that removing a high site would make a warming bias. That's like the southward march of thermometers fallacy. With anomalies, what counts is change - trends. And the suggestion is that higher sites warm faster.

    But the failure of my HiNepal model came because, as Zeke said, there just wasn't much high data at all over 2000 m, regardless of civil war.

  10. This is totally off topic, but an interesting (and perhaps easy) experiment you can do with the temperature data is produce two time series for the grid boxes that have both land and SST measurements. I mentioned this on Ron's blog, but didn't seem to generate any interest. I think it would be a neat illustration of the magnitude of the problems with the ocean measurements.

  11. cce,
    TempLS can't easily do that, because it isn't based on gridcells. I could probably compare sea in near-shore ribbon of say 200km, and a similar on-land. But a problem there is that SST temps aren't well localised. I place them at a grid centre, but that's arbitrary in a way that may matter for thin strip modelling.

  12. I'm not blowing you off, cce. Just too many irons in the fire at the moment. Combining looking at the issues and opportuinities of using multiple-data sources is high on my list of things to do.

  13. Thanks guys. I forgot TempLS is different.

    With multiple methods and multiple data sources, the number of experiments that can be done is endless.

  14. Cce,

    I'd be happy to run that for you next week once I finish up a post on GISTemp UHI adjustments. Should only take 15 min or so.

  15. Sounds like Moshpit is realizing that the whole pointing out of individual stations with counterintuitive corrections was silly, now. But he won't quite come to Jesus on it. Been a while since we've heard the "head for the ice" either. Looks like the surface record's not looking so bad. No need to head for the ice...

    Eschenback is just bad news and has been for years and years. gotta quesiton what ya got going on your side, with that fellow and his comparables. It's a hoot when he tried writing a paper and then complained about peer review and such...and the thing was a total mess of a blog post!