ryanickert
commented
5 years ago Simon, this is really good work, and IMO, looks like it would be worth publishing so that the rest of the community has a published touchstone on 204-overcounts. At any rate, it's super that you've taken the time to write this out so clearly and put it here. Thanks heaps for this.
Only obliquely related, but do you think that there are any issues associated with either 1) a breakdown of the poisson~gaussian assumption at low count rates (and non-phyisicality of negative count rates) or 2) The "ratio problem" illustrated by the Hawai'i group (e.g., Ogliore et al. 2011).
cwmagee
sbodorkos
Synopsis The expression coded by Ludwig in the SQUID 2.50 to deal with propagation of the uncertainty associated with the 204Pb overcount-correction looks foreign, and I am pretty sure it is incorrect mathematically. This note:
This document has NO direct impact on the Squid3 code. The relevant code for implementation will be documented (and 'debugged') elsewhere. I am using this Issue purely to capture notes and calculations that are 'new' to me, and to make those materials available to anyone wishing to examine my work. I decided to use an Issue rather than a wiki page because it's so much easier to embed files and images directly in an Issue; the Wiki pages seem to require URLs, which is a bit tedious.)
Introduction Count-rates at 204Pb are very low in many ion probe U-Th-Pb applications, which means measurements made at that peak are vulnerable to systematic sources of inaccuracy. In SHRIMP vernacular, 204Pb can be:
For simplicity, the following is confined to the 206Pb/238U vs 207Pb/235U systems, and the concept of "204Pb overcounts from 207Pb". (Analogous arguments are easily extended to the 206Pb/238U vs 208Pb/232Th systems, and the concept of "204Pb overcounts from 208Pb".)
One method for monitoring the accuracy of 204Pb measurements is via the use of an isotopically homogeneous reference material (Black, 2005: https://doi.org/10.1111/j.1751-908X.2005.tb00890.x, PDF Black-2005-GGR_Overcounts.pdf) which has:
The reference material has a constant, IDTIMS-determined [207/206]RM value, and we assume a constant composition for the common Pb components [206/204]c and [207/204]c. Then each spot analysis of the RM yields measured values of [207/206]m and [204/206]m.
In simplest terms, it is possible to calculate a "204Pb/206Pb from 207Pb" value ([204/206]7), which is essentially the [204/206] value needed for that spot in order to generate [207/206]RM from [207/206]m, for specified values of [206/204]c and [207/204]c:
This can in turn be used to calculate, for each spot, a "204 overcounts/second (from 207Pb)" value, which is essentially the excess count-rate measured at mass 204 (negative values represent count-rate deficits), relative to the 'perfect' count-rate dictated by [204/206]7. The equation is:
At the scale of individual spots, these calculations don't look very significant. But during a normal analytical session, an analyst would typically collect dozens of analyses of their 'main' isotopic RM, and even if individual 204ovCps determinations on a low-Pb RM have poor precision, there should still be statistical merit in the central 204ovCps value measured in a population of isotopically homogeneous RM analyses.
So, if there is no systematic inaccuracy in measured 204, and the RM is homogeneous, then the spot-specific 204ovCps values should be distributed approximately symmetrically about a central value of zero, with the extent of dispersion governed primarily on the 'prevailing' counting statistics during the session. In SQUID 2.50 and Squid3, the central 204ovCps value of the RM population is defined as the Tukey's biweight mean (tuning 9), and herein labelled XS204Cps (recalling that a negative value would be a 'negative excess i.e. a deficit). The uncertainty associated with XS204Cps is defined as the 95% confidence interval of the biweight mean, and is herein labelled DelXS204Cps.
Why does it matter? If the range defined by XS204Cps ± DelXS204Cps does not encompass zero, then an analyst might infer a systematic inaccuracy in their measurements at mass 204. A distinctly positive value can be taken to mean that some of the measured counts reflect an isobaric interference (rather than 'true' Pb); a negative value might mean that the measurement at 204 is not large enough to explain the full quantity of non-radiogenic Pb present.
In general terms, applying an appropriate correction to the measured [204/206]u of the unknowns on a spot-by-spot basis involves:
Context: Calculation of [204/206] and [Del204/206] Mass 204 is commonly characterised by very low count-rates, which means that the usual method of spot-ratio calculation in SQUID 2.50 and Squid3 (which involves inter-scan Dodson interpolation, followed by either linear regression to burn-midtime, or time-invariant weighted mean) is eschewed.
Instead, for ratios involving a numerator or denominator for which the total number of counts (across all scans) is less than 32, both SQUID 2.50 and Squid3 employ a method based on the "total counts" (which really means background-corrected counts) for the numerator and denominator. I have hand-worked (204206_measured_viaVBACode.pdf) the mathematical relationships described in the SQUID 2.50 VBA code, in order to derive and verify the expression implemented for [204/206] and [Del204/206]. The key equation is:
where CT204 and CT206 as the per-scan counting times (in seconds) for masses 204 and 206 respectively. For the value of [204/206], this equation can be reduced to the SQUID 2.50-testable equation governing spot-by-spot [204/206]m and [204/206]u:
This is intuitively sensible, and relatively easily derived from the 'first-principles' arithmetic documented in the SQUID 2.50 code. Equation (D) corresponds to my hand-worked RatioVal equation 6, near the top of p. 3 in the above PDF).
Determining the associated uncertainty is a bit more complicated, not least because SQUID 2.50 doesn't include any working; it simply specifies the expression used for the fractional error:
SQUID 2.50 does not supply total-count data on the StandardData or SampleData sheets, but in pages 3 and 4 on the above PDF, I have reverse-engineered the assumptions inherent in equation (D), and re-expressed it in a form that can be tested directly in a SQUID workbook (hand-worked RatioFractErr equation 12, at the base of p. 4). Defining Nscans as the number of scans in the analysis, and recalling the general expression governing 'TotXXXCounts' for any background-corrected mass-station XXX is:
then the the fractional error for [204/206] in equation (E) can be written as:
Applying the overcount-correction to [204/206]u Having derived one value for XS204Cps from the population of spot-by-spot measurements of RM [204ovCps (from207)] via equation (B), the next step is to correct each (spot-by-spot) measurement of [204/206]u for XS204Cps. The corrected ratio for each unknown is herein labelled [OC204/206]u, and SQUID 2.50 calculates the value directly from the source data (i.e. without direct reference to [204/206]u; I think this approach has been chosen to avoid the possibility of circular references):
This equation makes sense, and it satisfies the boundary condition. When XS204Cps = 0, equation (H) becomes:
Propagating the overcount-related uncertainty: the problem This is where things get difficult, because the SQUID 2.50 code does not contain any working. Instead, it simply specifies an equation:
Equation (K) looks completely foreign! Without knowing where it originates, it's very hard to tell whether it is correct or not. So I needed to determine whether this equation is correct (and its derivation is simply beyond my understanding), or whether it's incorrect. In the latter case, I needed to find and explain the error, and develop an "corrected" alternative that is both conceptually justifiable and arithmetically testable.
In this endeavour, I was greatly hampered by my own lack of understanding of the relevant considerations. I did a lot of algebra (and differential calculus!) that turned out to be mathematically correct in terms of its substituted variables, but which simply wouldn't give sensible answers when applied to the isotopic data.
In retrospect, there is a strong hint in equation (E): uncertainties on [204/206] must be calculated on the basis of total-count data; their Cps 'equivalents' are not an acceptable proxy. In reality, this should have been obvious: of course the number of scans and the count-times at the peaks are important factors in quantifying the uncertainty of an isotopic ratio, so it follows that these factors must be explicitly included in the uncertainty-related mathematics.
Importantly, this means that even though SQUID 2.50 presents Cps-based equations (D) and (G) to calculate the values of [204/206] and [OC204/206] respectively, those equations are not viable starting points for determining the uncertainties associated with those values, and upon closer inspection of [204/206] and [Del204/206], it is clear that equation (E) has been (correctly) derived from equation (C), not equation (D). Sounds simple, but it took me a full week, and 50 pages of botched math, to work it out...
How did Ludwig propagate the overcount-related uncertainty? I have taken a little comfort from the likelihood that Ludwig appears to have (at least momentarily) forgotten this too. His original code (verbatim from the Excel 2003 VBA Editor, with yellow highlight added by me) for calculating [DelOC204/206] is:
Term1–Term4 correspond sequentially to the indented lines of equation (K) above, with Term5 converting the absolute [DelOC204/206] to a fractional value. But the two highlighted Comments refer specifically to the variances of Cps values, which are not a substitute for total-count values. Furthermore, the contribution of background to the uncertainty of an isotopic ratio should not be considered explicitly in isolation; it should instead form part of the contribution of the background-corrected 'total-counts' measured at other peaks, as specified by equation (F). Note also that Ludwig's code-snippet makes no reference to "var tot206cts" or any nominal equivalent.
Before I really understood any of this, I did try to hand-calculate [DelOC204/206] starting (incorrectly) from equation (H), and determining partial derivatives from each of its four nominal components: [Tot204Cps], [BgdCps], [XS204Cps], and [Tot206Cps]. The hand-working is here: DelOC204206_CPSbasedAttempt_perLudwig.pdf. I have included it because I did end up with an equation quite similar to equation (K) as specified by Ludwig. Red ink in the final equation in the PDF highlights the differences between equation (K) and my hand-worked equivalent (which appears in the line above).
I am quite sure I have captured the substance of Ludwig's working, because I cannot find any other way to reproduce the distinctive coefficient of [BgdCps] (i.e. ( 1 - [OC204/206] )^2 ) in equation (K). I suspect Ludwig's omission of the 'Tot206Cps' term was deliberate: I guess he considered its coefficient (i.e. [OC204/206]^2 ) to be small enough to neglect. In practice, this is not a universally safe assumption, given that Tot206Cps is usually by far the largest number in this calculation, and also because in real datasets, it is not uncommon to see ABS([OC204/206]) > ABS([204/206]) at the level of individual spots.
Irrespective of that, it looks like the wrong approach, both because it deals in units of [XXXCps] rather than total counts, and because it treats [BgdCps] as an independent variable. But the real kicker with Ludwig's equation (K) is that it does not satisfy the boundary condition. If XS204Cps = DelXS204Cps = 0, then in theory, [OC204/206]u = [204/206]u and [DelOC204/206]u = [Del204/206]u. For the latter, the equation that would need to be satisfied is:
Dividing both sides of equation (L) by [204/206]u and factorising ( 1 / Nscans ) in an effort to make equation (L) look more like equation (G) gives:
It is clear that the right-hand side of equation (M) is not equivalent to that of equation (G), regardless of algebraic manipulation, because equations (K) and (L) employ CTBgd but not CT206. So in summary, I think the expression coded by Ludwig is wrong.
Propagating the overcount-related uncertainty: the solution I am convinced that the solution lies in treating the three (not four) components of [OC204/206] in terms of their total counts, and incorporating background implicitly. I hand-worked this (FINAL_DelOC204206_CORRECT.pdf) in two parts:
The second part starts by defining these three components in 'total counts at peak' terms, following equation (F):
Note that TotXS204Counts does not contain a background-related term, because it is a 'mass-balancing' quantity that corrects an excess/deficit in background-corrected Tot204Counts. Equations (N1)–(N3) can be rearranged to generate terms that can be substituted into equation (H), which governs [OC204/206] i.e.
In terms of the left-hand sides of these last three equations, the general form of equation (H) is:
However, it is critical to use the right-hand sides of equations (P)–(R) in order to obtain the correct form. Setting P = Tot204Counts, Q = TotXS204Counts, and R = Tot206Counts:
which simplifies to a critically modified version of equation (S):
From there, partial derivatives can be taken with respect to P, Q and R. Recalling that DelP = SQRT( ABS( P ) ), DelQ = Nscans CT204 DelXS204Cps, and DelR = SQRT( ABS( R ) ), the resulting fractional error can be written as:
The fractional error specified by equation (U) can be written in verbose (SQUID 2.50-testable) form as:
One way to check this equation is to apply the boundary condition: when XS204Cps = DelXS204Cps = 0, DelOC204/206] / [OC204/206] = [Del204/206] / [204/206]. So, setting XS204Cps = DelXS204Cps = 0 in equation (V):
Factorising ( SQRT( [Tot204Cps] - [BgdCps] ) )^2 from the numerator:
Cancelling the first and last lines of equation (X), and factorising ( 1 / Nscans ) from the remaining terms yields:
and equation (Y) is identical to equation (G) governing [Del204/206] / [204/206], as required by the boundary condition. On this basis, I intend to supplant Ludwig's expression with my own, in both the 'reference' version of SQUID 2.50, and in Squid3.
What effect does it have on the calculations? Below are the results from a random unknown (GA session 180050), for which the co-analysed RM defines an XS204Cps = +0.0055 and DelXS204Cps = 0.0381. There is nothing special about this dataset; it's just one I often use in SQUID 2.50 code documentation, because the Prawn XML file is relatively small, and rapidly processed. The value of [OC204/206] can be orders of magnitude different to [204/206], so their fractional errors are similarly afflicted. I have therefore chose to portray the absolute errors [DelOC204/206], as per Ludwig (red) and my revision (blue). Note that the y-axis is logarithmic.
Note that spots 6 and 13 are not part of this comparison, as their [204/206]m is sufficiently high that the values are calculated by inter-scan Dodson interpolation, rather than the low-count-rate arithmetic described herein. For context, the value of [OC204/206] to which these [DelOC204/206] values apply are labelled along the x-axis.
It is clear that my revision yields smaller [DelOC204/206] values across the board, but the magnitude of the difference is not obvious on the logarithmic scale. So I have re-expressed the revised [DelOC204/206] in terms of its percentage reduction, relative to Ludwig's [DelOC204/206]:
So in general, most of my revised [DelOC204/206] values are 30–50% lower than those calculated by Ludwig from the same input data, which is probably significant in terms of error propagation to 204Pb-corrected radiogenic ratios, especially 207Pb/206Pb values in the second half of the Proterozoic. This will need further investigation in datasets containing Harvard 91500 as a secondary RM (at some future time!).
These calculations can also be considered in terms of the increase in the size of the uncertainty associated with the overcount-correction, relative to the uncorrected [Del204/206] value. Below is a comparison of the 'inflation factors' for [DelOC204/206] according to Ludwig (red) and my revision (blue), normalised in each case to measured [Del204/206] in the overcount-free scenario (black line at AbsErr = 1).
Most of my revised [DelOC204/206] values increase yield values between 150% and 250% of [Del204/206], whereas the corresponding figures for Ludwig are probably 250–500%. The latter look high, but that doesn't necessarily make them wrong.
However, we can assess the merit of the two sets of arithmetic by ZEROing both XS204Cps and DelXS204Cps in SQJUID 2.50. This is achieved by manually overwriting each "204 overcts/sec fr. 207" value in the StandardData sheet with a zero, and pressing F9 to refresh the calculations, whereupon XS204Cps = DelXS204Cps = 0 for the purpose of overcount-correction calculation imposed on the co-analysed unknowns by selecting "Force 207Pb/235U–206Pb/238U concordance" in the Group Me dialog box.
As described above, it is intuitively reasonable to expect [OC204/206] to simplify to [204/206], and [DelOC204/206] to simplify to [Del204/206] in this situation. Below is the result of the corresponding [DelOC204/206] calculation for Ludwig (red), and my revision (blue), noting that in this case, my revision is identical to overcount-free [Del204/206].
Even on the logarithmic scale, it is clear that Ludwig's [DelOC204/206] arithmetic is adding a non-negligible component to [Del204/206], rather than matching overcount-free [Del204/206] as demanded by the boundary condition. The difference is even starker when considered in terms of the inflation factors (below): even when XS204Cps = DelXS204Cps = 0, Ludwig's arithmetic routinely results in [DelOC204/206] values that are 200–600% of [Del204/206], which surely can't be right.