Ratio mode - where we are, where we might want to go

[NicoleRayner]

There is a need to further develop the part of squid3 that processes non-geochronological data - AKA Ratio mode. This might be for purposes such as trace element concentrations experiments, or machine calibrating/testing purposes such as deadtime.

In ratio mode analyses there would be no built in expressions. Only Custom.

Currently squid3 can upload and process non-geochron xml files (e.g. ones with out Pb and U). You can define ratios and make custom expressions and save tasks but there are certain limitations. These include:

1. there must be a background peak. This is not always the case for non-geochron work and so one modification we would like would be to remove that as an option
2. Reference materials: The existing Parameter model/RM/CRM functionality would need to be tweaked/generalized. Ratio mode data MAY or MAY not be a reference material. Either would be permissible. When there is an RM, it is generic. The user would define what the constant names, values and uncertainties are in the this generic parameter model, It would behave like the U-Pb RM (i.e. it does not return values in the Custom expression Unknowns tab in Expression peek view, currently the CRM does).
3. Upload of squid2.5 tasks is inconsistent and "creating a new empty task" defaults to the Pb peaks + bkgd and cannot be deleted. I am not sure why this is and I generally can get around it but I am not sure quite how. Further investigations needed, including with a greater variety of datasets/tasks to troubleshoot this more fully. If other members of the community have non geochron xml files and associated tasks please upload them here and I can incorporate those into test. We at the GSC don't do a lot of it so finding example files to put things through it paces is a big help.
4. There is no option for "interpretation" in ratio mode. The only thing that we would probably want is the ability to calculate weighted means (user defined value) and "plot and 2" for both unknowns and RM.s

Attached are two zip files, one containing some test files for Ti in Zircon (9 peaking including a background) and another for deadtime (only 2 isotopes, no bkgd).

9P Ti in zircon tests.zip
Deadtime tests.zip

Each zip contains the raw data xml, the corresponding squid2.5 task, a .squid file that I built to play with and for Ti in Zircon only I also exported the task I started building in squid3 as an xml.

Do you have other thoughts? Please chime in.

[sbodorkos]

Hi @NicoleRayner – this is a really good list. I have some comments and suggestions too, plus I will loop in Chuck Magee @cwmagee to provide example Tasks and Prawn XML files dealing with our most recent iterations of trace-element data collection (our piezo stage is sufficiently repeatable that we can run a whole session of U-Pb analyses, then switch over the run-table to trace elements, then re-run the same schedule of spots for trace-elements).

With respect to non-compulsory background: This should actually be a universal feature i.e. it should (theoretically) be possible to create U-Pb geochronology Tasks that lack a background peak, as well as being able to do it in ratio-mode. This is documented at https://github.com/CIRDLES/ET_Redux/wiki/SHRIMP:-Step-2 and the relevant screenshot is given at the base of this post.

I imagine our current situation has arisen because we have never tested U-Pb geochronology using a Task or Prawn XML file that lacked a background-peak, which in turn would be a consequence of the indispensability of background when measuring 204Pb (and the latter is compulsory in Geochron mode: SQUID 2.50 requires all four isotopes of Pb to be measured for U-Pb geochronology, irrespective of whether you intend to use them all or not, and that requirement has been inherited by Squid3).

The solution is trivial enough: if a Prawn XML file and its Task do not identify a background mass-station, then background CPS should be set to zero. "Divide by zero" issues do not arise because background-correction is purely subtractive, and we already have provision in the code for when the subtraction yields zero-like numbers (e.g. when 204CPS = BgdCPS, then 204CPS - BgdCPS = 1e-32, etc.)

---

[bowring]

@sbodorkos - Squid3 v2.0.5 (new one today = 2.0.6) already allows for you to turn off the background in the edit task window, apply the task to the project, return to isotopes and re-synch the task ids to the data ids. The expressions now reflect the lack of background subtraction. This has never been tested out of the box on a no background prawn file since we don't have any! Cheers

[bowring]

ps, "turn off background" by setting the index to zero in the green box.

[sbodorkos]

@bowring yes, and I am hoping to remedy this situation at the beginning of next week on our SHRIMP, by collecting a "background-less" U-Pb dataset for the purpose of testing Squid3. If we can process that OK, we should be OK in ratio-mode as well.

I will try to unify at least a couple more of the Tasks and Prawn XMLs from Chuck's list above as well, but that might take a bit more time. I thought I had "background-less" ratio-mode Tasks and XMLs, but it appears I largely don't (beyond deadtime-tests of the kind @NicoleRayner has already supplied)

[cwmagee]

Here is a variety of tasks for various non-Pb related run tables:
SquidTask_B isotopes.CM.xls
SquidTask_KCa++.CM.xls
SquidTask_Rb++Sr++2.CM.xls
SquidTask_Trace in zirc-extend-trimmed.CM.xls
SquidTask_U-Th zircon long.JAV+CM.xls

[bowring]

@cwmagee - Thanks! I also need some data files to test these with. @bowring

[cwmagee]

There is a K-CA xml file in here:
K-Ca.zip
Everything else may need to wait until I am back in the office.

[bowring]

Thanks! This one works great for task importing. Squid3 still needs UI work for ratio mode however.

[cwmagee]

I think the K-Ca and Rb-Sr datasets have multiple backgrounds, one for each peak.
Here's a Rb-Sr one:
190048xmlzip.zip

[cwmagee]

Here's a U-Th disequilibria data file:
130014xmlzip.zip

[cwmagee]

Here is a zircon trace element xml:
230034TExmlzip.zip

[sbodorkos]

@NicoleRayner asked me to think about how Squid3 existing RM standardisation could be applied in ratio-mode (as opposed to U-Pb geochronology), and having spent a few days thinking about it, I'm not sure it can work. So much of what Squid3 does with ratio RMs depends on whether the scenario is Perm1 vs Perm2 vs Perm3 vs Perm4, which is in turn a consequence of specifying whether the RM constrains 206Pb/238U, 208Pb/232Th, or both... it is all so U-Pb-specific that we'd need to step outside all of it, and I have no idea how large a job that might be.

In the interim, I think we might have to make it pretty minimalist in ratio-mode, in terms of simply identifying a spot-prefix that is intended to correspond to the Ratio RM. The sole purpose of doing this would be to permit "standardisation" via Custom expressions, relative to a Ratio RM that the user has identified. I think it is probably similar for the CRM, especially if we envisage the possibility of "standardising" multiple elements (in U-Pb mode, only one element – U or Th – can be selected for normalisation).

[sbodorkos]

As promised last week, I attach a ZIP containing analyses conducting "canonical" U-Pb SHRIMP geochronology on zircon, but with no background peak. This experiment looks at how SQUID 2.50 and Squid3 deal with the backgroundless scenario, which can theoretically arise in both U-Pb geochron mode and ratio mode. The files comprise:

• an "8-peak" SQUID 2.50 Task (XLS = "SquidTask...")
• a matched Prawn XML file comprising 21 analyses each of TEMORA2 and OG1
• a "frozen" SQUID 2.50 workbook (XLS = "240014...", illustrating a procedural issue)

Backgroundless_Zircon_8peak.zip

In theory, no data-reduction issue should arise: the absence of measured background should lead to the universal assignment of BackgroundCPS = 0 and because background-correction is subtractive, no divide-by-zero issue arises that is not handled by existing code.

In practice, it doesn't quite work out that way in SQUID 2.50, and I am interested in whether the corresponding procedural issue arises in Squid3.

Data-processing "works" insofar as the code does not fail outright. However, Isotopic RM data-processing in SQUID 2.50 usually involves the creation of a column ["Bkrd cts/sec"] which contains the spot-specific count-rate at Background. It appears that in the absence of a designated Background peak, SQUID 2.50 does not create this column at all (in XLS file "240014...", it would usually be in worksheet StandardData, column J, to the left of ["total 196 cts/sec"]).

This leads to an issue in the RM data-processing, where spot-specific values of ["204 overcounts from 207Pb"] and ["204 overcounts from 208Pb"] (as well as the downstream robust means of these values) fail to calculate, because their built-in expressions require ["Bkrd cts/sec"] as an input. In XLS file "240014...", worksheet StandardData, see columns BG to BM for the calculations not performed owing to the absence (directly or indirectly) of column ["Bkrd cts/sec"].

I suspect that the pseudo-code I wrote (to port the SQUID 2.50 algorithms to Squid3) will have inflicted a similar problem on Squid3, but I have not yet had a chance to check.

The solution is trivial: in SQUID 2.50, it would involve ensuring that the ["Bkrd cts/sec"] column always exists, and that if no background-peak is specified, that ["Bkrd cts/sec"] is populated with spot-specific zeroes (in addition to the global assignment of BackgroundCPS = 0 in the pseudo-code). Perhaps Squid3 is better constructed, and "just works"!

[sbodorkos]

...Further to this, Antony Burnham has just tested the above Task and Prawn XML file in Squid3 v2.0.6, and it seems that all the blank columns in SQUID 2.50's StandardData sheet come out just fine in the analogous part of Squid3's RM CSV report. He has sent me his XLSX:

240014_backgroundless_zircon_8peak_RefMatReportTablePerSquid25.xlsx

I have also verified that the backgroundless calculations are functioning identically in SQUID 2.50 vs Squid3 with respect to the calculations that are being done: both yield a weighted mean 204-corrected 207Pb/206Pb date of 346 ± 37 Ma (95% confidence) across all 21 TEMORA2 analyses, confirming (unsurprisingly) that 204Pb is being "overcounted" in the absence of an appropriate background correction.