Luling Update
By Paul Homewood
Further to yesterday’s post on the massive temperature adjustments, made by USHCN, at Luling, Texas, there is some more information on the station location there.
Nick Stokes has commented:
I looked into this. The BEST analysis is here.
It seems that there was a station move in May 2011, and an almost immediate drop in temperature relative to the regional average of over 1°C. It looks like the USHCN algorithm is using the regional average until it can get a handle on the effect of the move. So of course the “adjustment” looks large.
So, I have taken a closer look at the station metadata, as supplied by NOAA.
It would appear that the current site, marked in blue, has moved by about 100 yds, although the altitude has been unchanged at 400 ft, hardly enough to cause the 1C change, which Nick suggests.
http://www.ncdc.noaa.gov/homr/#ncdcstnid=20024457&tab=LOCATIONS
However, delving deeper, we find these notes on the same station metadata.
http://www.ncdc.noaa.gov/homr/#ncdcstnid=20024457&tab=MISC
In other words, there has been NO STATION MOVE, only more accurate coordinates have been used.
NOT A LOT OF PEOPLE KNOW THAT 
Fascinating!
Time for Benedict Cumberbatch to make way?
Computer Programs can’t read and understand such notes, they just “react” as (erroneously?) programmed to the data.
Yes, it looks as if they may have just changed the lat/lon. But it was registered by BEST as a move, and probably by the NOAA system. The coordinates changed. And coincidentally or not, there was a dive in the relative temperature (according to BEST). Together, I think that would make the system replace the station data with infill from neighbours until it could figure whether there was a real shift. And since the relative temp is down, that explains the big number you are seeing.
A mythical move – but it is still used to manipulate the numbers. Yea, that is government work.
It does not explain the numbers. It is a poor excuse for manipulating the numbers. But excuses are not explanations. Or justifications.
“Yes, it looks as if they may have just changed the lat/lon” <—- Thats clearly not correct it states so in the notes on the station "NO EQUIPMENT MOVED".
Whats occurring is that a simple computer program is data mining areas for temperatures below certain stations.
So if in a Grid there is a warm station A in a large town and a colder Station B outside. The NOAA & BEST programs, discount B and use station A to estimate the data for B.
Its the Opposite of adjusting for UHI. The colder outliers are being "adjusted" up to the warmer stations.
Just because the temperature "Dropped" by one degree doesn't mean that this drop wasn't valid either.
Its as though both BEST and the NOAA system override temperature falls as "unexpected and problematic", then use the nearest "warm" station to override this data.
Essentially making both useless.
JustAnotherPoster June 27, 2014 11:53 am
“Yes, it looks as if they may have just changed the lat/lon” <—- Thats clearly not correct it states so in the notes on the station "NO EQUIPMENT MOVED"."
It also says:
“CHANGE ST INFO LAT/LON”
BEST registered it as a station move. I’m not imagining it. All I’m saying is that there probably was enough input to the computer, with change of LAT/LON and sudden drop relative to neighbours, to send it into wait and watch mode.
“All I’m saying is that there probably was enough input to the computer…to send it into wait and watch mode.”
No, Nick. The computer didn’t go into “wait and watch mode”. The computer adjusted the reported temperature upward. Wait and watch would be to report the actual temperature, then to either report the discrepancy to a human operator or to flag it for future…err…watching.
“there was a dive in relative temperature”
And of course we know that climate always changes gradually and never suddenly. Geesh.
“replace the station data with infill from neighbours until it could figure whether there was a real shift”
Perfect example of what’s wrong. Assumptions and confirmation bias programmed into the algorithms. And erroneous assumptions remain in place until a skeptic notices it, raises an issue. Pathetic.
The system could identify it as something to be checked, but nothing should be changed until a real problem was confirmed.
@Nick. If the temperature had jumped by 1 Degree in a positive manner, what would occur with the station data ?
Nick Stokes doesn’t know what happened or why, he is just guessing.
Neither do you. But at least I’m trying to figure it out. Most here don’t seem care about that. Just an excuse to bash USHCN. Facts would get in the way.
The facts are what is causing the bashing. The why is only important for excuses. The deed has been done.
The “mysterious” change then appears to be what everyone else calls “weather”.
Ohhhhhhhhhh NOES!
NOT weather
Excellent stuff, Paul. It seems Racehorse Stokes The Magnificent has descended from the sky in his chariot in order to point out your errors. You are scoring points. Keep it up :thumbsup:
@Nick
“I’m saying is that there probably was enough input to the computer, with change of LAT/LON and sudden drop relative to neighbours, to send it into wait and watch mode”.
If the temperature of a station Increases rather than falls does the same process apply ?
I see that several degrees of temperature are added without justification to a station simply because the “scientists” wanted warmer readings. But this is just one station and as I read that first post, this blogger (Paul) only got started looking. It was his first investigation as I understand it.
One out of One found to be fraudulent. (I hope the f-word is not banned here also like at WUWT) And the usual suspect is here to defend the fraud. It is all an honest mistake you see!!!! Heifer dust.
@Paul Homewood
Thank you for this investigative reporting. It is deeply illuminating.
I notice Nick isn’t replying to my question.
What would happen if the temperature increased as opposed to “dropped” ?
Would the same process occur or would it be accepted as OK rather than a “problem”.
I’m sure the algorithm works both ways.
“I’m sure the algorithm works both ways” <—— Massive LOL.
Bet you a million quid it doesn't.
That is the problem with the state of Climate Science today. All the idiots are sure – but they have no clue.
If you “think” it works both ways, then prove it. But do not give us assurances of your ignorance.
It seems odd that this station was at the top of the list you found. Why? Is that a list of tagged stations for investigations of data integrity or some such thing? Otherwise, this is one of the oddest coincidences in the history of weather station investigations.
——–
Nick Stokes seems to be trying to help and that is his way.
The last comment by J.A.P. wants an immediate reply to a question. Here’s a thought. I will post this comment (near 8:30 am; my time). Then I will check in and see what is going on at several other sites – might even see Nick is there commenting. Then I will turn my computer off for many hours to do some actual work and play things. I will check back either after dark tonight or early next morning. Maybe, likewise, Nick has some other things to do.
“Maybe, likewise, Nick has some other things to do.”
You may notice that my bear is marsupial. Yes, I do.
When site visits are made, (some) technicians will verify the coordinates listed on the B-44 station form. If they do not match, they will take new readings using newer GPS units and update the information. In some cases, old coordinates are so inaccurate that the station is placed on Google Earth 1+ mile away from where it actually is.
Mesoman speaks the truth, I have observed exactly the same thing in looking at metadata and in my site visits and interviews with COOP observers. One little known fact is that they always do the GPS reading over the rain gauge, not the thermometer. NWS cares much more about rainfall than they do temperature for forecast verification and hydrometeorological purposes.
Slowly, the entire network is being converted to better GPS readings. A lot of the early coordinates in metadata were only to two decimal points, and early GPS readings often had navigation offsets. These are often falsely interpreted as station moves, and can be particularly troublesome for BEST, who relies on station move detetction to create “new” stations.
The network was never designed to detect global warming, it was all about forecast verification, and still mostly is. Hell, global warming wasn’t even a concept when it was put together in the 1890’s along with the formation of the U.S. Weather Bureau with Stevenson Screens, copper rain gauges, and Mercury thermometers.
Photographic evidence of where the station was in 2007 : (Apologies in advance if link does not work)
https://www.google.com/maps/place/29%C2%B040'31.8%22N+97%C2%B039'27.7%22W/@29.675513,-97.657882,3a,90y,129.6h,81.12t/data=!3m4!1e1!3m2!1snSvTjjjl-pL9ogpGGKMoBg!2e0!4m2!3m1!1s0x0:0x0
mesoman permalink
June 27, 2014 4:06 pm
On the original Thread about Luling you stated that the Unit was reading low in 2013 compared to another station 5 miles away.
Can you provide the number for that other stationas the closest one I could find is San Antonio, which strangely enough was also reading low for that period and was also switched to Estimated results during 2013.
It also has many groups of years where only Estimated values are used.
The station I compared it to is mine. I live 5 miles away from the Luling COOP site, and have a Davis Vantage Pro2 with aspirated radiation shield, located in the middle of a large (maintained) grass field. I verify the Davis system every 6 months against a calibrated lab thermometer. I was suspicious when daytime temperatures in sunny, breezy, well-mixed conditions were sometimes 8-12 degrees cooler at the COOP site, which didn’t make meteorological sense.
When I went to investigate the Luling MMTS, my control thermometer inserted into the shelter showed an average MMTS error of -3.6 F degrees over the 30 minute comparison, with larger individual sample differences. I traced the problem to damaged cabling that was causing the temperature readout system to calculate temperatures incorrectly. After the cable was replaced, the MMTS showed an average error of -0.4 F, which is within tolerance.
mesoman, was that cable damage in the ground, at the sensor, or at the readout?
I’ve noted lawnmower damage is sometimes an issue from banging into the side of the MMTS pole which the cable is often strapped/taped to down to the ground. The cable sometimes gets crimped or its insulation torn/exposed.
Another interesting thing is that NWS personnel only have a test plug for the end of the cable, which when looking at the readout indoors will tell them if the cable/display is working correctly, see it here: http://www.srh.noaa.gov/srh/dad/coop/mmts_images/display_testplug.JPG
Source page: http://www.srh.noaa.gov/srh/dad/coop/install_mmts.html
They have no way to actually test the sensor itself across its range in the field that I am aware of. Like mesoman did, they can do a spot check with a handheld thermometer…they do point to this handheld thermometer from the source page above: http://www.forestry-suppliers.com/product_pages/Products.asp?mi=2102
Anthony, the cable damage was around the pole that supports the sensor, which is a common location for damage due to what you mention: lawnmowers and weed trimmers. Most of my sites now have their cables pulled through PVC pipe up to the bottom of the sensor to prevent this problem. MMTS cable problems are probably even more common than people realize; I spend more time out in the field repairing the cables and plugs than any other activity. Physical damage, corrosion, tiny insects/spiders squeezing into and gumming up the plug pins, and other things, can all cause erroneous temperature readings.
Another method we use in addition to thermometer comparisons, which I did at Luling, is to cut off the plugs, twist together the wires at one end, and do a resistance check across the circuit. Values outside the range indicate problems within the cable rather than the sensor or Nimbus readout (which isn’t good news because it means ditch digging!).
Thanks, Mesoman,
That does seem to fit the facts quite well. And whether by good luck or good management, the system responded appropriately. Let’s see if they restore soon.
I looked through the station’s hardcopy file, and the equipment has been at its current location since September 20, 1995.
SO the first station Paul chose had an update three and a half years ago, Nick Stokes claims that All I’m saying is that there probably was enough input to the computer, with change of LAT/LON and sudden drop relative to neighbours, to send it into wait and watch mode.
This begs two questions,
1. What are the odds on Paul’s single selection being the only example of this type of “no change” update is in the dataset?
2. How long does it take the for problem to be resolved and the station be removed from wait and watch mode?
My answers
1. Highly unlikely
2. It’ll never happen
I’ll give Nick the benefit of the doubt. So show me actual data where the algorithm works both ways.
R2Dtoo
“So show me actual data where the algorithm works both ways.”
Why don’t you look?
Someone as cynical as me….. Obviously a programmer.
Nick Stokes pointed out, quite properly, that the “correction” of recent data followed both a reported re-siting of the station and a significant drop in temperatures. What is now clear is that the “correction” should not have been made. There is still no apparent reason for the adjustment the other way of 1934 data.
For twenty-five years I worked as a management accountant in manufacturing. Every year the figures were audited, to establish if the figures that the businesses accounting department compiled were a “true and fair view” of the reality. This included random samples of such figures as inventory and assets. If any of the samples showed an error, a correction would be required. More importantly, the sampling would be extended to determine whether this error was part of a systematic problem. If it was, a fundamental recalculation of the figures would be required, or a note placed in the accounts.
We have an example of error that biases the figures towards warming. Steve Goddard has shown an increasing warming bias in the US figures, and he and others, have previously shown a warming bias in GISTEMP global figures. It appears that there exists in average temperature estimation a situation analogous to accounting in the 1980s. That is, when businesses manipulated figures and created rules as they sought fit. Often those adjustments superficially had quite good justification, but the impact of failing to provide a “true and fair view” was that some businesses that reported as being sound went bust a short while later.
Well put Manicbeancounter.
There are also companies that keep one set of books for the auditor and the real ones
hidden in a safe somewhere.
In this case the ‘real’ set has been repeatedly overwritten by warmer and warmer ‘enhanced’ versions in an effort to replace the truth and to blot out an inconvenient history.
This, however, is the age of the internet. While those who lived through the ‘dust-bowl’ years in the 30’s may soon all be gone; the internet never forgets.
I made some shaded plots of the anomalies around Luling during the peak months of 2013. There is definitely something odd happening there.
Neither do you. But at least I’m trying to figure it out. Most here don’t seem care about that. Just an excuse to bash USHCN. Facts would get in the way.
Nick Stokes,
I certainly don’t guess about what happened.
The road to damnation is paved with good intentions.
Just say you don’t know which from your reply you don’t have any better ideas than anyone else?
I do care very much about what happened, I’d like to know why a purely administrative update leads to all these problems, how many other edits to information cause this sort of issue? With more automation will comments like UPDATED INFO TO REFLECT PAPERLESS OPERATIONS cause more problems like this one? Does anyone know? A lot of expensive decisions are made on the back of this data.
Nick I posted this over on the thread you linked to
Nick, I have a question, how many of the “local” stations that you plotted data for were Estimated values for 2013?
I have just looked at the first 10 files in the USCHN Texas zip and 3 (30%) were estimated for 2012 through to the current month.
Also 7 of them had large sections of the beginning of the 20th century estimated, with a couple right up to 1930/40.
All of them had many sections estimated throughout the century.
AC, As I said over there, all the stations have raw data. It is taken from the GHCN unadjusted file, and can be traced to the CLIMAT forms, or here, even to the B91’s filled out by the operator.
I think your commentary is confusing two situations. There are indeed many Coop stations that have stopped reporting, often simply because the volunteers can’t do it any more. There USHCN infills because there is no raw data. Nothing wrong with that; the only requirement is that there is enough data from somewhere. And you can see from the plots that I showed that the US is in fact densely covered with reporting stations.
The situation you confuse it with is where a station is producing data which is quarantined for some reason. Then you can compare and see the difference, which this post did. The homogenisation software is designed for just this purpose; that data which is reflecting non-climatic issues can be detected and excluded (since there is plenty of good data). And that’s exactly what happened here. The system worked as it is supposed to.
To expand on the early 20th century estimating here is what I found in the first 10 files
USH00011084 Es from 1898 to 1934
USH00012813 Es from 1894 to 1919
USH00013160 OK
USH00013511 OK
USH00013816 OK
USH00015749 Es from 1898 to 1934
USH00017157 Es from 1894 to 1940
USH00017304 Es from 1893 to 1897 & 1924 to 1931
USH00017366 Es from 1892 to 1896 & 1903 to 1907
USH00018024 Es from 1892 to 1900
So why have estimated data, is it because there was none, in which why quote those at all, or have the values been changed?
CLIMATEGATE TROIS