GISTEMP 2009 anomaly anomaly

In a previous article I predicted that the 2009 GISTEMP anomaly would be +0.58. In fact when it was published it came in at +0.57. This 0.01 K difference is well within any reasonable error bounds and typical of the sort of error you get from rounding. Still, it bothered me. How unlucky was I to get agreement for all the years except the most recent one?

Today I realised that although I was using up to date land data I wasn’t using up to date ocean data. I have just fetched fresh ocean data and rerun ccc-gistemp. Of course the 2009 anomaly comes out as +0.57 K, same as GISS:

5 Responses to “GISTEMP 2009 anomaly anomaly”

  1. jl Says:

    thank you for your hard work!!!

  2. steven mosher Says:

    FWIW, other guys have the same problem, probably just a set up thing. I’m kinda busy but I’ll keep fiddling

    mosher:ccc-gistemp-0.2.0 mosher$ python code/
    MISSING: input/antarc1.list
    MISSING: input/antarc1.txt
    MISSING: input/antarc2.list
    MISSING: input/antarc2.txt
    MISSING: input/antarc3.list
    MISSING: input/antarc3.txt
    MISSING: input/t_hohenpeissenberg_200306.txt_as_received_July17_2003
    MISSING: input/ushcn2.tbl
    MISSING: input/ushcnV2_cmb.tbl
    MISSING: input/mcdw.tbl
    MISSING: input/ushcn2.tbl
    MISSING: input/sumofday.tbl
    MISSING: input/v2.inv
    MISSING: input/9641C_200907_F52.avg
    MISSING: input/v2.mean
    MISSING: input/SBBX.HadR2
    Attempting to fetch missing files: antarc1.list antarc1.txt antarc2.list antarc2.txt antarc3.list antarc3.txt t_hohenpeissenberg_200306.txt_as_received_July17_2003 ushcn2.tbl ushcnV2_cmb.tbl mcdw.tbl ushcn2.tbl sumofday.tbl v2.inv 9641C_200907_F52.avg v2.mean SBBX.HadR2
    Extracting members from
    Traceback (most recent call last):
    File “code/”, line 205, in
    File “code/”, line 177, in main
    File “/Users/mosher/Downloads/ccc-gistemp-0.2.0/code/”, line 80, in checkit
    fetch.main(argv=[‘fetch’] + missing)
    File “/Users/mosher/Downloads/ccc-gistemp-0.2.0/code/”, line 265, in main
    File “/Users/mosher/Downloads/ccc-gistemp-0.2.0/code/”, line 166, in fetch
    handler[hname](group, prefix, output)
    File “/Users/mosher/Downloads/ccc-gistemp-0.2.0/code/”, line 201, in fetch_tar
    fetch_from_tar(u, members, prefix, output)
    File “/Users/mosher/Downloads/ccc-gistemp-0.2.0/code/”, line 218, in fetch_from_tar
    tar =’r|*’, fileobj=inp)
    File “/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/”, line 1168, in open
    File “/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/”, line 1047, in __init__
    File “/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/”, line 402, in abspath
    File “/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/”, line 49, in isabs
    AttributeError: ‘NoneType’ object has no attribute ‘startswith’
    mosher:ccc-gistemp-0.2.0 mosher$

  3. Nick.Barnes Says:

    Yes, Steven, this is a bug in Python’s tar library in certain versions of Python. It only affects the fetching of those particular source data files from the GISTEMP source tarball. You can work around by manually fetching and unpacking the required files from it into the input/ directory in ccc-gistemp-0.2.0. You can figure out the required files (and where they live in GISTEMP_sources) by looking at our

    Or you can upgrade to a later Python, or try our current sources from SVN (we have put in a work-around).

  4. Nick.Barnes Says:

    Alternatively, you can fetch
    That’s a single complete set of input files, from December. Untar it and copy the input/ directory to ccc-gistemp-0.2.0/input

  5. drj Says:

    The tarfile thing should be fixed (in all versions of Python from 2.4.2 onwards) by the recent release 0.3.0.

Leave a Reply