SQ2.50 arithmetic comparison via custom ReportBuilder CSV

[sbodorkos]

I have worked my way through a very simple example for the Unknowns, and overall everything looks good arithmetically. There are some issues with the exact form of the CSV data, but nothing major.

1. The main thing is that Report Builder CSVs specify all Ages and their 1sigma absolute errors as annum, not Ma. It will be important to integrate expression evaluation and a-to-Ma conversion very closely, because people write Custom Expressions that explicitly assume Built-in Ages are in Ma (and that is not an unreasonable thing for people to do). Unfortunately, the annum-values are not yet completely "cloaked" from users, which leads to expressions that are arithmetically and anatomically perfect but scientifically useless. See below (and attached), where Custom Expression "MF_corr.%Disc." features an argument to the exponent has been constructed assuming the units of "MF_corr.4corr.7/6 Age" are Ma... and the output is scientifically meaningless because that (reasonable) assumption is false.

2. Primary Beam (nA) values are negative in SQUID 2.50, but positive in Squid3. Thinking about this, I am guessing that the sign of the PBM current (as written to Prawn Data XML by the SHRIMP control software) is governed by the polarity of the instrument, and therefore primary beams comprising negatively-charged oxygen molecules/atoms ought to be defined as having negative currents? But I might be wrong about that... @NicoleRayner ?

3. A discrepancy affecting direct comparisons is in the SQUID 2.50 "magic numbers" corresponding to Squid3 Reference Material Values L1033 and L859 (and I would presume it affects L9678 as well, although I did not intersect that in my example). SQUID 2.50 uses those values rounded to the significant figures implied by the variable-names (i.e. 1.033, 0.859, and 0.9678 respectively). In contrast, Squid3 retains the full lineage of each number, including its evaluation at full double-precision. There's nothing wrong with the Squid3 implementation, it just yields slightly different results. In doing my comparison, I added a multiplicative factor to force recalculation of Squid3 values using L1033 = 1.033 and L859 = 0.859, and the resulting match with SQUID 2.50 was certainly good enough for Government work!

4. I have been off the pace here, so apologies if it has been dealt with... but I have noticed that Squid3 simply ignores a handful of the Custom Expressions specified in the SQUID 2.50 Task. In the one attached here, the following 6 Unknown-specific Custom Task-equations have been passed over altogether:

Calibration Error (%) CalError Expo-RR EXPO-USED MF_corr. 4corr. 7/6 Age (Ma) abs. err. QC Status

From the outside, it seems that these could have been dumped (with their Excel-text formulations intact) in the Unhealthy Expressions list... is there something that stops this happening?

Sq3-147_GSC-836_SQ2.50Task.zip

[cwmagee]

PBM values are negative because the current is negative.

The PBM measures the net current flowing into the sample stage in order to maintain Sample Potential at the set value (usually 10,000 volts). There are about four components to this, but in the absense of an electron gun, the main contribution is the primary beam, which consists of negative ions (O2- in most of our runs). When we bombard with O2+ (such as the experiments we did a few years back on rutile), the PBM is positive.

Technically, in a electron gun absent setting, the PBM is: primary ion beam current (-) - secondary ion current (+) + tertiary electron current (-) (tertiary electrons are electrons knocked off of the extraction plate and/or acceleration cone by medium-to-high energy secondary ions and neutrals- these electrons are pulled back onto the sample by the sample potential).

In short, the PBM polarity is physically meaningful, as it explains whether the sample is gaining or losing electric charge from the ion beam(s).

[NicoleRayner]

@sbodorkos

• Good catch on the annum/Ma thing. I will keep an eye out for that.

• Not sure where you are seeing positive Primary beam values in SQUID3, mine are negative in data audit and in Expression Manager/Spot Metadata. In any case, if one wishes to use it in an expression it can just be made ABS.

• Some of those missing expressions refer to named cells which might explain why they don't show as unhealthy. Another "QC status" is a column filled with text so might also not flag as an oddball. These little bugs/discrepancies don't seem worth tracking down as they relate to our workflow here at GSC, not data reduction

[bowring]

Please supply the task file (or at least its name if I already have it) for number 4 so this can be investigated.

[sbodorkos]

@bowring it's in the ZIP

[bowring]

On point 4 above, missing expressions:

Currently, expressions that refer to items that have not been defined are skipped altogether. This is the case for: 1) CalError : is the name of an expression 'ErrorinStandardCalib.' that is not defined anywhere 2) Calibration Error (%) : is the name of an expression 'ExtPerrA1' that is not defined anywhere 3) Expo-RR : is the name of an expression 'Expo', this is defined - this actually an bug/oversight as we initially required single names to be in brackets and quotes, but now allow their use. 4) EXPO-USED : ditto for Expo_used 5) QCStatus : is the name of an expression ' "ACCEPT" ' that is not defined anywhere and if it were, should be 'ACCEPT' or ["ACCEPT"] 6) MF_corr. 4corr. 7/6 Age (Ma) abs. err. : this is a complicated case because the definition is "AgeErPb76(["MF_corr.4corr.7/6"],["MF_corr.4corr.7/6%err."],,,,true)", which Squid3 specifically ignores, because the function "AgePb76" produces both the age and the 1-sigma abs uncertainty, assuming the input 207/206 ratio expression contains a value and 1 sigma abs uncertainty as well. However, in this task, the expression for the age is "AgePb76(["MF_corr.4corr.7/6"])" and "MF_corr.4corr.7/6" is defined as "4cor_207Pb206Pb*["MassFract.Factor"]" , which does not include the uncertainty.

There are two current Squid3 solutions: First Solution: is to re-define "MF_corr.4corr.7/6" as "ValueModel(4cor_207Pb206Pb["MassFract.Factor"], [±"4cor_207Pb206Pb"]["MassFract.Factor"], true)", or switch to percent uncertainty and use "ValueModel(4cor_207Pb206Pb["MassFract.Factor"], [%"4cor_207Pb206Pb"]["MassFract.Factor"], false)".

Second Solution: Replace the definition of "MF_corr.4corr.7/6 Age" with "AgePb76WithErr(4cor_207Pb206Pb["MassFract.Factor"], [±"4cor_207Pb206Pb"]["MassFract.Factor"])". (note the abs uncertainty used)

This follows the tooltip for AgePb76: This function is based on Isoplot's AgePb76, which calculates the 207/206 age from the 207/206 ratio.However, since Squid3 ratios of interest of the form [\"206/207\"] have an associated uncertainty, invoking AgePb76([\"206/207\"]) will also return the 1\u03C3 abs uncertainty of the age. To calculate a 76 age with uncertainty from separate values of ratio and ratio uncertainty, use the Squid3 function AgePb76WithErr(ratio, unct). The underlying function is Isoplot's PbPbAge, found at "https://github.com/CIRDLES/LudwigLibrary/blob/master/vbaCode/isoplot3Basic/UPb.bas".

Please remember that the next stage of Squid3 development is to build a Task-management system to preserve these translation changes and reduce the dependency on Squid2.5 tasks.

Comments welcomed!

[sbodorkos]

I understand why the expression don't evaluate, and I don't expect Squid3 to remediate that. What I don't understand is why wholesale 'skipping' is the appropriate treatment for expressions referring to undefined items.

Why not just dump the unimproved Excel-text for such expressions under Unhealthy Expressions/Mismatched Targets, so that users can at least try to sort out the issues? Quite often a solution does exist for tenacious Task-translators e.g. ExtPerrA1 from SQUID 2.50 is equivalent to element [2] of the (zero-addressed) vector of outputs from Squid3's WtdMeanA output for the Reference Material.

No-one expects those sorts of translations to be automated, but at present you don't even get the option of trying to repair them manually.

[bowring]

v1.4.8 does just that (coming soon).

[bowring]

@sbodorkos - Let's revisit these issues in one of our meetings to determine next steps.

[NicoleRayner]

I think this issue can be closed. Some issues are resolved in recent versions, others might (or might not) need further fleshing out but that should be done by specific, new issues. (I would close it but since it isn't my issue, I am not able).