Saturday, March 23, 2013

Proxy viewer with choice of dating and range



In a previous post I showed an active viewer for the Marcott et al proxies, and in the next I described the code. There has been interest in various extensions, to give the option of showing the revised dating of Marcott et al, and also to show a closeup on more recent times.

This is a combined viewer that does those things. The format change is simply that there are a few more entries in the key table, in black at the start. They are
  • "AuthHolo", for Published (author) dating, -50 to 11300 BP
  • "MarcHolo", for Marcott et al dating, -50 to 11300 BP
  • "Auth2000", for Published (author) dating, -50 to 1950 BP
  • "Marc2000", for Marcott et al dating, -50 to 1950 BP
If you click on any of these, it will change to that scale. You have to click again to select a proxy.





23 comments:

  1. Nick, switching between Marc and Auth doesn't quite work.

    The selected curve remains as it was originally drawn in black, giving the impression that it wasn't modified by Marcott's processing.

    (I'm looking at proxy 57 at the moment.)

    ReplyDelete
    Replies
    1. Carrick,
      I think this is the issue that I made a note about. When you change the dating, the background changes, but you still have to then re-select the curve, even if it's the same one.

      Sounds like bad design, but it's to make the swap work. But I will try to improve it.

      Delete
    2. Carrick,
      I've clarified it by making the old black curve go away when you choose a new spag plot.

      The swap facility with different datings does show up the changes.

      Delete
    3. Nick, sorry that I missed that. (I'm too prone to skip words and go straight the meat. ;-))

      I like the visual layout of the table btw. That's usually the hardest part to get right.

      The conceptual use of AuthHolo, MarcHolo, etc to modify the graph in particular is pretty clever.

      Delete
  2. Since you didn't mention it here, see proxy's 54 and 58. I had presumed that the effect of the redating was uniformly to shift the proxies forward during the last 2000 years. These show the reverse effect.

    This paper is to me more interesting because of the global set of proxies that it aggregates, rather than is methodology or results.

    The reason I say that is because, as a methodology paper, it contains too few details to be replicable and as a results paper, the focus is wonky (as a global mean temperature with circa 300-year resolution, it provides little new information as far as I can tell).

    It might be interesting to see a breakdown of the reconstruction into extra-tropic SH, NH and tropics. (Then again it might not be, if the temporal resolution of the proxies if poor enough.)

    ReplyDelete
    Replies
    1. Marcott did a latitude breakdown in Fig S10.

      Delete
    2. I think all the SST proxies, plus a few dozen others, were already available in the GHOST database, updated for Leduc et al. 2010. That paper is worth a read for a different take on these proxies in the context of the Holocene. They have a stronger discussion of the factors, other than annual temperature, which can affect different proxy types on millennial timescales - particularly how insolation shifts can alter relationships. The key point is that large NH mid and high latitude millennial temperature trends found in alkenone proxies are not seen in Mg/Ca proxies, even at the same sites. As Marcott et al. show in the SI, removing this handful of proxies produces a flat Holocene.

      Delete
  3. Another odd one is proxy #6.

    How do you justify moving the date by a 1000 years?

    ReplyDelete
    Replies
    1. Carrick,
      This question was raised at Climate Audit. What M did was to move to the assumption of age=0 at coretop. That is often reasonable, if the coretop is close to the fluid interface, where it must be age=0 (or correctly, the real present time).

      The dating information for that proxy was:
      14C depth 14C age
      (cm) (yr BP)
      14 1980
      54 3216
      96 4275
      So the original 1000BP was an extrapolation.

      This core goes back 32000 years in 13 metres.

      Delete
    2. Nick: This question was raised at Climate Audit. What M did was to move to the assumption of age=0 at coretop. That is often reasonable, if the coretop is close to the fluid interface, where it must be age=0 (or correctly, the real present time).

      This is certainly outside of anything I have experience with... however, it does seem odd to me to not consult with the authors before redating, which from what little description they've given doesn't seem likely.

      You don't automatically know for example, whether the reported values goes to the fluid interface for example. I think the conservative thing to do is trust the original author's analysis in a case like this

      Delete
    3. Carrick,
      I think original papers generally see the depth as the controlling variable, so it may not matter for their analysis whether date is monotonic. But if you want to switch to temp being a function of date, it can be a problem. At least, as Paul says, the graphs look funny.

      There was such a case, OCE326-GGC30, Discussed at CA, where Sachs had assigned a date of zero to the top eight levels, though the temp varied. The CA complaint was that: "However, once again, the Marcott calculation truncated the most recent values."

      But what else? They can only have one value for time=0.

      Delete
    4. It's not that odd, being typical of what you get when plotting one variable against an other, both having measurement error.

      Relating to "what else", one way to handle this is to use a LOESS curve to resample the x-y data (I think Gergis did something similar), rather than trying to treat the original x values as errorless. I'd probably work on a frequency based method that didn't shift energy between frequency regions, but that'd be a serious research project.

      From my own experience, when you have measurement error in "x" (time here, frequency in my case) and pin your curve to one point, there's an artifact that show will up just with that point. In other words, he may be assuming the date versus temperature curves all pass through 1950 (for the ones where he recalculated the date), when in fact you should allow them to have an uncertainty, since the dates aren't accurately known.

      I'm not saying that's the origin of the glitch on the end-point for Marcott, but it's a possible explanation. Of course, it's hard to discuss what Marcott actually did, without seeing his code.

      Delete
  4. Minor error found with the MD97-2122 proxy: The dates at the top are not listed linearly with time in the original published column. You can see on your graph there's a little loop at the end.

    ReplyDelete
    Replies
    1. Paul,
      That's a tricky one. The published dates are not monotonic with depth, but Marcott has straightened that out. In the original, they took pairs of C14 dating points close together:
      C14 depth Age Error
      58.5    2203    56
      106.5    3280    20
      110.5    3241    56
      190.5    4830    20

      110 is younger than 106, but within the error range. That's the basic problem.

      I think these issues often just didn't matter to the original authors, who weren't trying to do time series analysis.


      Delete
    2. Actually you don't know that 110 is really younger, right? There's measurement error here in C14 as well as depth.

      I also suspect they were planning on using the time series in further analyses. Otherwise, why gather therm?

      Delete
  5. Nick I think you have Agassiz & Renland in the wrong location, and as a 'chimaera' of the lat of one and the lon of the other... both are in Greenland. See Vinther et al 2009. But the Excel table messes this up also, giving a longitude of 26.7 which should be West.

    ReplyDelete
    Replies
    1. Ah, yes. The Excel gave two latitudes and two longitudes, for the two sites. I took the first number of each, which obviously wasn't right. I'll fix. Maybe even a second dot.

      Delete
    2. Martin,
      I think the error is in the original XL. The first figures should have been Renland, but Marcott left off the minus sign on longitude.

      Delete
    3. martin,
      Sorry, I see that you already noted that.

      Delete
    4. Yep. Note that also the elevations are in the wrong order in the XL. But I believe this was compiled after the fact and Marcott used the right data. The Vinther et al. data they used is already elevation (uplift) corrected, and I assume that this applies throughout. And the supp. info gives a picture with Renland in the right spot, but Agassiz outside the map frame and not plotted.

      You have two options for using this data approximately correctly: 1) assign it to the mean of the two geographic locations; 2) assign one copy each to each of the two locations. I would prefer 1, being (a little) more conservative.

      Delete
    5. Martin,
      "You have two options for using this data approximately correctly: 1) assign it to the mean of the two geographic locations; 2) assign one copy each to each of the two locations. I would prefer 1, being (a little) more conservative."

      It depends on what you mean by "using". This post just displays; I should really create two dots, but that's quite a lot of infrastructure work for one site. I could show the mean position, but I don't think that helps much. I'll get the text metadata right.

      In terms of my simplified emulation, location only enters into the weighting. The two sites would be in different grid cells, and if treated separately would get double weighting. If there were separate data that would be right, but if they are just copies of the same data, I don't believe it is. It's not clear to me how a location error would affect Marcott's analysis either, except again possibly through weighting. But that's only true if the move shifts cell weight, and sites are sparse there.

      The other possible effect would come if there was a zonal boundary involved, but I don't think there is.

      Delete