Uncorrected Pb/U calibration values

[carrpatrick]

Squid3 Version: 2.0.9
Java Version: 1.8.0_151
JavaFX Version: 8.0.151-b12
OS: Windows 10 10.0

Issue details: Hi all,

I'm relatively new to Squid so forgive my ignorance.

I'm having trouble understanding how the uncorrected Pb/U calibration constants are calculated in Squid 3 as I don't get the same results as when I calculate them manually in excel.

For an example, the following are SHRIMP-II (Curtin) U-Pb analyses on the M257 zircon reference material.

The 'Uncorr Pb/U const' column was data generated in Squid 3 version 2.09 (SBM normalisation on; spot average ratio calculation, Task is the GA 9 pk zircon with fixed slope of 2), the 'constant calculated from excel' column is calculated as follows (206/238)/(254/238)^2.

<style> </style>

	206 /238	% err	254 /238	% err		Uncorr Pb/U const	% err		constant calculated from ratios	%diff (squid vs calculated)
SQUID 3-2.09
M2A-1.1	0.202732	3.4	6.625	1.049		0.004582	1.29		0.004619
M2B-2.1	0.200658	2.3	6.65	0.917		0.004496	0.68		0.004537
M2A-3.1	0.207	3.3	6.726	1.289		0.004532	0.94		0.004576
M2B-4.1	0.185386	2.4	6.385	0.768		0.00452	1.24		0.004547
M2A-5.1	0.195214	2.6	6.562	0.782		0.00455	0.39		0.004534
M2B-6.1	0.200025	3.4	6.656	1.003		0.004486	1.53		0.004515
M2A-7.1	0.197333	3	6.604	0.997		0.004485	1.05		0.004525
M2B-8.1	0.2056	2.9	6.719	1.084		0.004559	0.4		0.004554

The difference between Pb/U constant calculated by Squid and in excel is variable and up to 1% and I can't figure out why.

I have the same problem using Squid 2.5; the values are similar to Squid 3 to the 6th decimal place (probably a rounding difference?)

The difference in the final weighted mean Pb/U constant between the Squid 3 output and my excel calculation is 0.11%..

What am i missing?

Any help would be greatly appreciated.

Pat

[sbodorkos]

Hi @carrpatrick , thanks for this. Very briefly: the Pb/U calibration constant is evaluated numerically, via Dodson interpolation of all the constituent peaks between scans; it's not evaluated just using the 'spot-mean' values of 206/238 and 254/238 for each analysis.

The easiest way to visualise what's going on is in SQUID 2.50, by looking at the Within-Spot Ratios sheet (if you don't have one, visit the Preferences, tick the appropriate box, and reprocess your data). Scroll to the right until you find a set of 3 columns labelled "4corr 206Pb/238U calibr const" (or similar), which comprise the interpolated time at which the constant was evaluated (between scans), the interpolated value of the constant, and its 1sigma absolute error. Note that the number of rows per analysis is one less than the number of scans in the analysis, owing to the interpolation. For the set of data-reduction parameters you've described, calculating a weighted mean of those calibration constant values (e.g. using Isoplot) ought to give you a value closely similar to that specified on your StandardData sheet for the corresponding analysis. BUT there is a column-labelling issue which I haven't worked out to my own satisfaction yet: I had thought that "4corr 206Pb/238U calibr const" on the Within Spot Ratios sheet gave rise to the "Uncorr Pb/U const" cell on the StandardData sheet, but that does not seem to be the case. I need to dig a bit deeper there.

In Squid3, the corresponding exercise is a bit more awkward. Go to the Reports menu, and work your way through the sequence: Misc. Reports - QuickView Reports - Reference Materials - within Spots. The Squid3 window will fill with a space-delimited text-file analogous to the Within Spot Ratios sheet in SQUID 2.50. Select All, Copy into a blank Notepad file, and Save as txt. Then Import that file into Excel (via Get Data) and bring it in as Fixed Width (Excel ought to auto-detect this). Just use the default column-settings - it combines a few of the leftmost columns, but that doesn't really matter for this purpose. Scroll across to the right, and you ought to find a set of 3 columns named "Uncor_206Pb_238U_cali" corresponding to Integration Time, Value and 1sigma absolute error. From there, same weighted-mean as SQUID 2.50 above. Compare your result to the single-cell values per-spot reported in the RefMatReportTablePerSquid2.* file output by Squid3 (both the UncorrPb/Uconst and the 4-corr 206Pb/238U calCon).

Having said all that, there are still some discrepancies that I don't remember how to account for. I will review the documentation to trace out the rest of the calculation-path. Any question, please let me know.

Cheers Simon

[carrpatrick]

Hi @sbodorkos

Thank you for this explanation.

To confirm, I have selected the ratio calculation method as Spot Average (time invariant).

So, a Dodson interpolation is performed on the individual isotopes of both reference materials and samples to generate the isotope ratios? Doesn't the 'Linear regression to burn mid-time' perform this same function?

The reasons for my confusion were that in the Expressions tab it appears as if the isotope signals (CPS), ratios, and the 'Uncor_206Pb238U_CalibConst' are calculated from the spot average data with no mention of interpolation.

Cheers
Pat

[sbodorkos]

Hi @carrpatrick , a few different strands to disentangle here.

The early calculations, culminating in the isotopic signal (CPS) values, are calculated directly from the ion-count (and SBM-count) data collected at each peak, for each scan, in an intuitive way. I have described these early steps at https://github.com/CIRDLES/ET_Redux/wiki/SHRIMP:-Step-1 and https://github.com/CIRDLES/ET_Redux/wiki/SHRIMP:-Step-2 , and the calculations are trivial - you can replicate the values for an example spot of your own, without any difficulty.

Isotope ratios are more complicated. Dodson double-interpolation happens every time, and Ludwig describes the mathematics in the SQUID 2.50 User Manual on printed page-numbers 43-46, under the heading 'Within-spot isotope ratios'. Unfortunately the accompanying plain-English commentary is quite poorly written, so it's hard to get a greater sense of what is actually happening. The mechanics of generating the double-interpolated ratio-values and their errors are described here: https://github.com/CIRDLES/ET_Redux/wiki/SHRIMP:-Step-3 , but it is pretty tedious, granular stuff.

The double-interpolated ratios and their errors always form the basis for the 'spot-mean' ratio value and error (where 'spot-mean' refers to the value and %err placed on the StandardData or SampleData sheets in SQUID 2.50/Squid3 for a given ratio, for a given spot). If you choose 'Spot Average (time invariant)', you get a weighted mean of the double-interpolated ratios and their errors. If you choose 'Linear regression to burn midtime', the regression is performed using the double-interpolated ratios and their errors. The processes for generating the 'spot-mean' and its %err are described conceptually here: https://github.com/CIRDLES/ET_Redux/wiki/SHRIMP:-Step-4 , but in practice it is pretty difficult to follow, because of the need to step into and out of separately-documented subroutines.

Numeric-switched Task expressions are more complicated still, because although their values are double-interpolated as well, they do not use the double-interpolated values of their constituent ratios (i.e. as generated above). Instead, each expression-value is double-interpolated to a time calculated using all of the constituent peaks in the expression (e.g. 206, 238 and 254 in the classic calibration-constant expression). Your 232Th/238U Task expression (if you use one, in preference to trying to calibrate both Pb/U and Pb/Th independently and directly) will have its double-interpolated values calculated in the same way. The process is documented here: https://github.com/CIRDLES/ET_Redux/wiki/SHRIMP:-Sub-EqnInterp , but it is painful stuff.

I do have some hand-worked examples i.e., for one spot, a spreadsheet that starts with the ion-count, SBM-count, and integration-time data, and implements the programmatic steps sequentially - over a lot of different cells and columns - to drop out spot-mean values and %errs for isotope ratios and Numeric-switched expressions (e.g. uncorrected calibration constant) at the other end. The worked examples were on a DropBox account which has now been deleted, but I can restore those links; it will just take some time.

Cheers
Simon

[carrpatrick]

Hi Simon,

Thanks for this. I'll ask around Curtin for the worked examples. It would be good to have these accessible somewhere - although i imagine not too many people will come looking for them.

Pat

[sbodorkos]

Hi Pat, no worries. I'm on leave at the moment, but I will have a crack at restoring the links inside the Squid3 wiki tomorrow.

Getting the right version of each file will be the hard part - really wish I had remembered about this stuff when DropBox told me my account was expiring!

[sbodorkos]

Hi @carrpatrick , I think it's done: you should be able to start from here: https://github.com/CIRDLES/Squid/wiki and all the various links (to PDF, ZIP, XLS and XLSX) should now work.

Some background (as broadly outlined by the Home page above): Squid3 was originally intended to be a "clone" of SQUID 2.50, primarily representing a 'port' of the SQUID 2.50 algorithms from their VBA 6 environment (in Excel 2003) into Java. That's why so much of the commentary is SQUID 2.50-centric. We had a few problems to overcome:

1. Nobody really knew how SQUID 2.50 worked (even though everybody completely trusted it!).
2. It wasn't clear whether it was even possible to elucidate the algorithms from Ken Ludwig's VBA codebase into Excel spreadsheets where everyone could "see" them.
3. I definitely didn't know whether I was capable of doing it, having only 2 years of maths from my undergrad, and no programming or VBA experience.
4. Because I obviously don't have Ken Ludwig's standing in the international isotopic community, it was imperative that I be able to replicate his outputs "exactly" (without any real understanding of what "exactly" meant), as a kind of proof that I knew enough about what I was doing that the SHRIMP community could take me seriously.

So, for forensic matching of spreadsheet outputs with SQUID 2.50 outputs at the 14-15 significant digit-level, it's necessary to use the June 2015 version of SQUID 2.50 in Excel 2003 (available from https://sourceforge.net/projects/squid2) alongside the various XLS[X] files linked in the Squid3 wiki. Because as we went along, we unsurprisingly found errors in Ludwig's code (it's remarkable how few there, are given that Ludwig wrote it all himself, with essentially no peer-review) that needed to be repaired. The fixes have been incorporated into Squid3, but it was not always straightforward to enact them in "improved" versions of SQUID 2.50 (although I did try, via release of Squid2.50.20.10.26 in October 2020). The result has been that SQUID 2.50 and Squid3 outputs have gradually diverged over time.

If you need a copy of Squid2.50.20.10.26, and/or any of the presentations that Jim Bowring and I gave when formally launching Squid3 in early 2021, please let me know. Or any other questions for that matter.

Especially let me know if having the XLS files opening in Google Sheets is a pain. You should be able to use File... Download... to get hold of XLS files for Excel 2003, but if that's not possible, I'll post ZIP files alongside each link, so you can control the process more directly.

Cheers Simon

[carrpatrick]

Thanks Simon,
It would have been a daunting task!

I'll try and follow the logic with these sheets. They seem to work ok in googlesheets, although I haven't gone all the way through yet.

[sbodorkos]

There's not much "why" in the Excel files - it was just me trying to implement stepwise arithmetic and hoping it would get me to the right place. There is some scaffolding in the Squid3 wiki (in terms of which column- and row-blocks go together, and what is happening at each step), and the corresponding ET-Redux wiki page (linked from each relevant Squid3 wiki page) specifies the pseudo-code for each named entity along the way. The ET-Redux pseudo-code was what Jim Bowring used as the basis for coding Squid3 in Java.

The section at the base of each page, labelled 'Sanity Check' is the report I requested from Jim to ensure that the Java code was replicating the Excel-based arithmetic at each step.

And you've probably already worked it out, but the entity referred to as 'Calamari' in the wiki pages has since been folded into the production version of Squid3 - it's no longer a separate entity.