bowring
commented
3 years ago @sbodorkos - As we have discussed, Squid3 currently models specified ratios to have two pairs of value fields: (ratioVal, ratioFractErr) and (ratioValUsed, ratioFractErrUsed), where the naming derives from the Squid2.5 math and FractErr refers to 1-sigma absolute uncertainty. The first pair - (ratioVal, ratioFractErr) - is assigned values after the "NU-switched" processing and remains immutable. Initially, the second pair - (ratioValUsed, ratioFractErrUsed) - is given the same values. Every expression referring to ["204/206"], for example, is given the values from the second pair - (ratioValUsed, ratioFractErrUsed) to use in its calculations.
The current practical use of this model in Squid3 is in implementing the 204 overcount corrections. When the user chooses the correction (from 207 or from 208), a built-in expression (see: CountCorrectionExpression204From207 and CountCorrectionExpression204From208) is used to calculate the corrected ratio and uncertainty and Squid3 modifies the ["204/206"] ratios accordingly by writing the new values to the ratio's second pair - (ratioValUsed, ratioFractErrUsed). All expressions are then re-evaluated and any reference to ["204/206"] retrieves these corrected values. This change is reflected in the Expression Manager's Peek window for "Ratios with uncertainties". When the user chooses to not use an overcount correction, Squid3 simply copies the values from the immutable first pair - (ratioVal, ratioFractErr) - to the second pair - (ratioValUsed, ratioFractErrUsed).
The general case of column-swapping for ratios is more complicated.
One possible solution is to create three new Squid3 functions to be used in writing custom expressions: 1) ORIG(["204/206"]) or ORIG([+/-"204/206"]) that would ALWAYS return the immutable original NU-switched values.
2) SWAP(["204/206"], ValueModel(value, 1-sigma abs uncertainty, true)) that overwrites the second pair - (ratioValUsed, ratioFractErrUsed) with the warning that internal use of ["204/206"] instead of ORIG(["204/206"]) is a circular reference. These new values from SWAP() would be returned by any reference to ["204/206"]. One complication here is that if overcount corrections were made first, the use of ORIG() would not return these corrected values.
3) RESTORE(["204/206"]) that copies the immutable first pair into the second pair of values so that they would be returned by any reference to ["204/206"].
Another, less-powerful and possibly more practical solution is to replicate the overcount corrections window. In this case, a table would be presented with a row for each ratio. The first column has the names of the ratios, the second column has radio buttons restoring the immutable value to the ratio in the same row, and the third column has radio buttons each selecting the named expression to its right that would be used ONCE to overwrite the second pair of values - (ratioValUsed, ratioFractErrUsed) for the ratio in that row. That expression would be written, named, and managed in the expression manager. The use of ORIG() here might be useful to avoid overcount corrections or to reference another ratio's immutable values. The main advantage of this solution is that Squid3 would guarantee that the expression is only applied once to the ratio, as in the case of overcount corrections.
Have a headache yet?
This promises to be an interesting discussion!
an interesting footnote: expression 10 can be written as: if(["204"]==["BKG"],1e-32,(["204"]-["BKG"])/(["206"]-["BKG"]))
cwmagee
sbodorkos
NicoleRayner
Jim @bowring, further to multiple previous discussions and long-promised actions, I have attached a SQUID 2.50 Task that 'post-processes' measured values of 204/206 in order to exclude negative values. These occur when count-rates at background (mass 204.1) exceed those at 204Pb (mass 204), which on the GA instrument happens a bit more often than we'd like.
SquidTask_ILC Zircon 10pk exp=2 AllPos204.GA.xls
The Task replaces values of 204/206 below +1e-7 (both positive and negative) to a revised value of +1e-7. When that revision happens, the associated %err is set to 9999. Spots with 204/206 exceeding +1e-7 retain their original value and %err,
Unfortunately, the SQUID 2.50 process is quite convoluted, because all FO-switched expressions get re-evaluated as the expressions are sequentially executed, so it is important for the user to recognise and avoid potential corruption of the data processing as a consequence of circular references. The absence of an explicit definition of 'original' and 'revised' isotopic ratios means Task-writing is tedious. For example, equation 10 defines ["Orig204/206"] as:
if(["Total 204 cts/sec"]=["Bkrd cts/sec"],1e-32,(["Total 204 cts/sec"]-["Bkrd cts/sec"])/(["Total 206 cts/sec"]-["Bkrd cts/sec"]))which is the exact implementation of the 204/206 ratio-calculation (for very low count-rates) coded in SQUID 2.50 and Squid3 "under the hood". But in SQUID 2.50, we can't write the much simpler (and equivalent-looking Task equation for ["Orig204/206"]:
["204/206"]because ["204/206"] is going to be modified by the column-swap, and re-evaluation of ["Orig204/206"] as a consequence of the column-swap will mean that ["Orig204/206"] will end up not being the original measurement of 204/206 after all.
Equations 11-13 evaluate the associated absolute uncertainty of 204/206 at low count-rates, again following the under-the-hood calculations. Equation 14 simply chooses the larger of ["Orig204/206"] and +1e-7 as ["New204/206"], and Equation 15 correspondingly sets the percentage error of ["New204/206"] to either 9999 or the %err associated with ["Orig204/206"].
Equations 16 and 17 showcase the column-swap syntax developed by Ludwig. The general form is ["CalculatedValue"]<=>["OriginalValue"].
The effect of these equations is to force ["New204/206"] into the data-processing space formerly occupied by ["204/206"], and likewise ["New204/206%err"] instead of [+/-"204/206"], and then refresh all calculations (both under the hood and throughout the Task). This is why equation 10 is written the way it is: there is only one ["Orig204/206"], and I do NOT want it re-evaluated!
A by-product of equations 16 and 17 are columns labelled "RAW 204/206" and "RAW 204/206 %err", which are supposed to contain ["OriginalValue"] data as it stood prior to the column-swap i.e. these data should be directly comparable to the outputs of my equations 10 and 13. The idea is that whenever you modify an isotopic ratio using a column-swapping Task, you retain a record of the original values, so you can find your way back if you need to.
As discussed in previous Skype-calls, can Squid3 potentially perform these tasks more easily? Perhaps by reliably identifying "original" and "modified" versions of isotopic ratios for the purpose of expression evaluation, thereby sparing us the need to respecify important calculations from scratch so we don't end up with inaccurate re-evaluations after the column-swap?
Essentially, I would like to be able to write equation 10 as:
["204/206"]
and have Squid3 "know" that I intend that expression to relate solely to the original value of 204/206, and not be re-evaluated in the event of a column-swap. But it's trickier than it looks, because in most situations (and particularly the downstream processing that calculates radiogenic ages), real users do want those expressions re-evaluated as a result of column-swapping.