Incorrect identification of the reference peak in a task

[AllenKennedy]

I loaded a rutile and then a titanite task. The first has a Ti3O3 reference peak , and the second a CaTi2O4 reference peak. Both reference peaks were identified as Th peaks by SQ3.

[sbodorkos]

Hi @AllenKennedy , the issue here is the relatively crude logic Squid3 uses to try and 'guess' for each mass-station whether it is a U-bearing peak, a Th-bearing peak, or neither (None). Squid3 essentially bases its guess on the user-specified (in the SHRIMP Control software) Label of each mass-station, remembering that Squid3 does not demand nuclide-by-nuclide specification of each peak in the run-table during Task construction, the way SQUID 2.50 did.

In terms of an immediate fix, note that Squid3's guesses are user-editable. In the Manage Isotopes window, if you right-click on the "Thorium" part of the CaTi2O4/Ti3O3 row, it should open a small drop-down list containing "Uranium", "Thorium", and "None". Select "None", and you've corrected Squid3's guess. (As we refine the user-interface, I'd like the existence of that dropdown to be advertised by a little downwards-pointing triangle; we'll get to that in due course).

I am not exactly sure how Jim @bowring has implemented the guess-logic, but I too have noticed spurious Thorium peaks in the past, in some of your REE-bearing Tasks. Based on your issues, I suspect the Label search might be solely on upper-case "T". If this is the case, the logic could be tidied by refining the search string to case-sensitive occurrences of "Th". Assuming that U-bearing peaks are being detected based on the occurrence of upper-case "U" in the Label, we probably don't need any changes.

@bowring , an additional measure that might help mitigate misdiagnosis of "None" peaks as U- or Th-bearing would be to designate a minimum Trim Mass, below which all peaks are "guessed" to be "None". I don't think we would want to be too prescriptive about how good the magnet field calibrations are from lab to lab (because unlike SQUID 2.50, Squid3 does not mandate a maximum permitted divergence between the nominal mass and the true mass of any given peak), but I think we could say that any mass-station with a trim-mass less than (say) 228 amu should default to "None" rather than "Uranium" or "Thorium", regardless of what the mass-station label says. In theory, sub-228 peaks should be too "light" to contain any U or Th (with the exception of double-charged ions, which I think we can safely leave to users to configure manually, as per my instructions to Allen above).

[bowring]

1) it would be nice to have the raw data file and squid file for examination 2) currently, the logic is: if the elementName contains any of "238, 254, 270, u, U" , it is U-bearing, else if the elementName contains any of "232, 248, 264, t, T" , it is T-bearing, else none My conclusion is that there is an anomaly in the data, which I need to investigate once I have the files. On further reflection, I think the test for "T" is the culprit most likely.

[sbodorkos]

And again, with the security-tag this time :(.

---

From: Bodorkos Simon Simon.Bodorkos@ga.gov.au Sent: Wednesday, 4 September 2019 6:44:39 AM To: CIRDLES/Squid Squid@noreply.github.com; CIRDLES/Squid reply@reply.github.com Cc: Comment comment@noreply.github.com Subject: Re: [CIRDLES/Squid] Incorrect identification of the reference peak in a task (#354)

Yes... Although there are broad hints in the information provided, assuming Allen gave us literal mass-station labels (elementNames), both of which contain upper-case T:

CaTi2O4 Ti3O3

One of our issues is that the chemical symbol for thorium is (case-sensitive) Th, and literal dealings with the periodic table of the elements is one scenario in which case-sensitivity should be enforced. So my case-sensitive suggestions for the search-strings are:

Thorium: 232, 248, 264, Th Uranium: 238, 254, 270, U

Abolishing lower-case matches will also prevent future spurious U-matches on rare-earth element-bearing peaks such as europium (Eu) and lutetium (Lu), which could conceivably be incorporated into U-Pb run-tables.

Using the above search-strings will result in "false negative" auto-guesses on elementNames where the SHRIMP analyst has not respected the case-sensitivity of the periodic table, but I am comfortable with that. It's definitely a better scenario than "false positives" on correctly formulated elementNames, which is the basis of Allen's issue.

---

From: Jim Bowring notifications@github.com Sent: Wednesday, 4 September 2019 1:45:09 AM To: CIRDLES/Squid Squid@noreply.github.com Cc: Bodorkos Simon Simon.Bodorkos@ga.gov.au; Comment comment@noreply.github.com Subject: Re: [CIRDLES/Squid] Incorrect identification of the reference peak in a task (#354)

1. it would be nice to have the raw data file and squid file for examination
2. currently, the logic is: if the elementName contains any of "238, 254, 270, u, U" , it is U-bearing, else if the elementName contains any of "232, 248, 264, t, T" , it is T-bearing, else none My conclusion is that there is an anomaly in the data, which I need to investigate once I have the files.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/CIRDLES/Squid/issues/354?email_source=notifications&email_token=AEFJ5MYJGAKNZYTEGQWFLWLQH2BALA5CNFSM4ISKKBGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YUOCI#issuecomment-527517449, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEFJ5M5J7Q7ZIDFYG3RPT53QH2BALANCNFSM4ISKKBGA.

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.

[cwmagee]

If the logic calls anything with "t" or "T" thorium, then that is the problem. Minerals with titanium in them (Ti) usually contain a bit of uranium, and thus are sometimes used for dating. They will generally have a Ti-bearing matrix peak in the run table, as Allen describes. So the logic is too permissive. After all, people who are also interested in trace elements might slip Eu, Lu, Tb, or Tm into their run tables (either as elements or as oxides). And people trying to quantify surface contamination will occasionally measure Au, to see how effectively the raster sputters away the gold coat.

[bowring]

We will adopt the case-sensitive specification by @sbodorkos Thorium: 232, 248, 264, Th Uranium: 238, 254, 270, U

[bowring]

Fixed in release v1.3.0 beta - but note we have no way to test it as an example file has not been submitted. Please report if it works properly.

[sbodorkos]

@bowring, following up yesterday's Skype, here is a file that should allow you to test your fix. The screenshot below contains the answers that Squid3 should give:

and a ZIP of the corresponding Prawn XML files for testing is here:

MattCoble_MC78-UO2vUF_17060115.23.zip

[bowring]

Test successful, screen shot attached