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
Posts
Nick, switching between Marc and Auth doesn't quite work.
ReplyDeleteThe 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.)
Carrick,
DeleteI 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.
Carrick,
DeleteI'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.
Nick, sorry that I missed that. (I'm too prone to skip words and go straight the meat. ;-))
DeleteI 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.
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.
ReplyDeleteThis 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.)
Marcott did a latitude breakdown in Fig S10.
DeleteI 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.
DeleteAnother odd one is proxy #6.
ReplyDeleteHow do you justify moving the date by a 1000 years?
Carrick,
DeleteThis 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.
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).
DeleteThis 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
Carrick,
DeleteI 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.
It's not that odd, being typical of what you get when plotting one variable against an other, both having measurement error.
DeleteRelating 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.
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.
ReplyDeleteShould be MD97-2121 #48
DeletePaul,
DeleteThat'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.
Actually you don't know that 110 is really younger, right? There's measurement error here in C14 as well as depth.
DeleteI also suspect they were planning on using the time series in further analyses. Otherwise, why gather therm?
Oops - I replied here
DeleteNick 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.
ReplyDeleteAh, 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.
DeleteMartin,
DeleteI think the error is in the original XL. The first figures should have been Renland, but Marcott left off the minus sign on longitude.
martin,
DeleteSorry, I see that you already noted that.
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.
DeleteYou 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.
Martin,
Delete"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.