87Sr/86Sr DRS?

Bence

I've just checked through the code, and when you change the Reference Material in the DRS settings, it should then use that Ref Mat in the calculations. Did you get values for the "StdCorr" channels (e.g. "StdCorr_Sr87_86")?

Regarding the Rb and CaAr bias: these were added to adjust for the effect of Rb and CaAr not necessarily having the exact same mass fractionation bias as Sr (or rather, not the same as that determined from the measured Sr isotopes). Many labs just leave this at 1, but you could see if changing it (normally by less than a few percent) and seeing if it has a positive effect on your results. It really depends on whether there really is a difference between, for example, Rb and Sr fractionation in your instrument.

Bence

amzipkin

Hi Bence, I am going to email you a copy of a project file where this occurred, as well as the .json file that I created for the NanoSr standard. I cannot find any channels with the prefix StdCorr but the output channels do include Sr8786_Corr and the values there in are mostly in line with what I am expecting for these specimens (not great, but within a few hundred ppm or less of the expected ratios).

Thanks for the explaining the Rb and CaAr bias parameters; will discuss with the geochemist I am collaborating with at ASU who is usually responsible for the Neptune end of things while I deal with the laser and resulting data.

Bence

Hi amzipkin ,

Thanks for sending those files through. It was actually a simple issue: the Ref Mat used during the DRS execution is only updated if the text in the Ref Mat selector changes. Because there was only Ref Mat in your experiment, and the selector was set to this value by default, the text never changed, and so the DRS was not updated with the correct Ref Mat name.

Anyway, I have fixed this and pushed a fix to the github repo: https://github.com/iolite-LA-ICP-MS/iolite4-python-examples/tree/master/drs

Thanks for pointing this out to us. And yes, it's not unusual to get roughly the right numbers for your 8786_Corr ratios. The StdCorr_8786 ratios are corrected to the accepted value of your Ref Mat. If the _Corr ratios are pretty close, this final normalisation step will have little effect.

Thanks again,
Bence

amzipkin

Hey Bence,

I downloaded the entire repo as a zip file using the green code button as you described a couple of weeks ago, deleted the old Sr_isotopes.py file in my DRS folder, and copied in the new .py file. I also installed the Trace Elements Multi-RM DRS for future use. When I restarted Iolite both the Sr isotopes and the Multi-RM DRSs showed up. Multi-RM looks fine, though I have not actually tried using it. Sr isotopes, however, throws an error. It says "There was a problem getting the settings widget" and directs me to my messages where the below error appears. Anyway, I'm assuming this is a stupid, easy fix if you point me in the right direction. Thanks for the update to the DRS to fix the RM bug; I'm eager to see how bracketing standard correcting my previously reduced affects the final values,

Time	Origin	Message
30:13.2		Error Type: <class 'IndexError'>

Error Value: tuple index out of range
Error Traceback: File "C:/Users/Documents/iolite/Plugins/Data reduction schemes/Sr_isotopes.py" line 206 in settingsWidget
rmComboBox.setCurrentText(rmNames[0])

amzipkin

Ok, possibly scratch that. I was clicking on the DRS without any data loaded. Not sure why the Multi-RM DRS drop down fields appear just fine while the Sr isotope DRS threw an error and didn't show show the usual interface, but when I load data the Sr isotopes DRS suddenly works. All the parameter fields appear, no line 206 error, it crunches the data, and also no longer shows the reference material error from a few days ago.

Bence

That error will only appear if you have a single RM group for the Sr isotope DRS. I haven't looked at the code for the Multi-RM DRS for a while, and it's dropdown menu code might be quite different.

Yes, you'll get an error if you try to crunch with no data loaded. In the future we'll try to pretty this up by letting you know before you try to crunch.

amzipkin

Hi Bence (and anyone else knowledgeable on the following),

I have been using the Sr isotope DRS pretty successfully for the last month now but my understanding of what's going on under the hood could use some improving. I am trying to better understand the various corrections that are implemented in the DRS and how they compare to how I would process solution MC-ICP-MS radiogenic Sr data. First, Iolite does a baseline subtraction for all channels (in my case, based a ₃₀ second pre-ablation gas blank for each measurement). Is this essentially equivalent to doing an on-peak zero online correction in which the signal on a gas blank is subtracted from all the m/z channels being measured (i.e., it should be able to handle krypton interference with masses 84 and 86)? Second, what additional corrections are implemented in the DRS? I assume a mass bias normalization (using 88Sr/86Sr = 8.375209, exponential law) because that is pretty standard. Based on the tunable parameters in the DRS, there seems to be a correction for calcium argide interference on multiple m/z channels relevant to strontium, and a correction for Rb interference on masses 85 and 87. Is that correct? What about a correction for Ca dimers?

Lastly, how does the standard reference material factor in? For the strontium isotope DRS, is it used like a solution bracketing standard in which the unknowns and secondary standards are normalized to an offset model? By this I mean that the spline fit to the bracketing standard measurements predicts what the measured value of the standard would be in between actual analyses of the standard, calculates an offset from its reference value, and corrects the unknowns accordingly by subtracting the difference.

Thank Bence, Joe, and anyone else with the expertise to weigh in. I'm just trying to equate how Iolite is handling my LA data with the way I process solution data to make sure that I am generating results from the two methods that use the same corrections.

Bence

Hi Andrew,

Below I've included references to lines in the python code that is available here (https://github.com/iolite-LA-ICP-MS/iolite4-python-examples/blob/master/drs/Sr_isotopes.py). These line references assume you haven't modified the code at all.

The DRS begins by subtracting the background from each channel (lines 77 - 81). It then calculates a preliminary fractionation factor PFract from the observed intensities on m/z 88 and 86 (line 99 in the code). This fractionation factor is used to remove the interference of 46Ca40Ar and 48Ca40Ar on masses 86 and 88, respectively (lines 100 and 101). An updated fractionation factor Fract is then determined from the interference corrected 86 and 88 masses (line 102). The Rb87 interference on mass 87 is then removed (lines 103-105), using Rb85 and the new fractionation factor. There is an option to adjust the Sr/Rb fractionation factor (that is, if you believe that Rb is not fractionated to the same extent as Sr, you can adjust it using the 'Rb Bias' variable).

The 42Ca40Ar inteference on Sr84 is then subtracted in the same manner (lines 106-108). Similarly, there is an option to adjust the CaAr fractionation factor from the observed Sr fractionation factor using the 'CaAr Bias' variable .

The 88 and 86 masses are interference corrected again (similar to lines 100 and 101) but now with the updated fractionation factor Fract (lines 109-110).

With the interference corrections completed, the DRS then calculates several corrected and uncorrected ratios (lines 115-119). In this case, 'uncorrected' refers to ratios using the non-interference corrected channel values. For example, 'Sr8786_uncorr' is the ratio of mass 87 to mass 86 before CaAr interference correction, but mass fractionation corrected using the final Fract factor. The '_corr' ratios use the interference corrected channels, with the final Fract factor. Estimates of the Rb contribution to m/z 87 and CaAr to m/z 84 are also calculated (lines 120-121) as well as the total Sr signal (the sum of the correct Sr84, Sr86, Sr87 and Sr88 channels).

Finally, the DRS normalises the corrected 87Sr/86Sr ratio to the accepted value for the reference material (line 145) to create the channel StdCorr_Sr87_86. This is done by multiplying the corrected 87Sr/86Sr values by the accepted value of the standard and dividing by the spline of 'Sr8786_corr'.

If you have any questions about the above, please just let me know by replying in this thread.

We hope to release a new DRS that combines the CaAr and REE interference corrections soon. Just waiting on a collaborator's go-ahead.

Best,
Bence

amzipkin

Thanks Bence; this is all great detail. I am looking forward to trying the new version of the DRS.

amzipkin

Hi Bence,

I just found the newer DRS that combines REE interference corrections with CaAr and Rb corrections on Github and installed it. Is any documentation about how to use this DRS (and about what is happening under the hood) available? Either an update to the Iolite4 manual, a Notes blog post, or a YouTube video explainer? Or perhaps your collaborator actually published a peer-reviewed study that uses and validates the new DRS?

Thanks,

Andrew

Bence

amzipkin

Hi Andrew,

This DRS is still a work in progress, but we hope to have it out soon (in the next month or so). We'll include some documentation and references to the original work it's based on when we release it.

More info to come!

-Bence

amzipkin

Aaand just to make things interesting on a Friday, the older Sr isotope DRS (Sr Isotopes Example, which I downloaded fresh from Github today and installed on a new computer) is throwing a novel (to me) error:

There was an error in your python runDRS function: : std::runtime_error: Cannot overwrite an input channel with an intermediate or output channel: Sr87 File "C:/Users/azipkin/Documents/iolite/Plugins/Data reduction schemes/Sr_isotopes.py", line 129, in runDRS data.createTimeSeries(name, data.Intermediate, indexChannel.time(), channel)

Now, unlike my past use of the Sr Isotopes DRS, I am trying to process data generated using an iCAP TQ ICP-MS operating in TQ mass shift mode, not MC-ICP-MS data. This is method development work to assess whether some recent claims of generating reliable 87/86 results on a quad are viable. However, it doesn't appear to be an issue with the type of data that I am loading to Iolite. When I examine the input channels in Iolite, they correctly recognize the pre-shift mass and post-shift mass for those analytes (82Kr, 83Kr, 84Sr, 87Sr, and 88Sr) that underwent an O2 mass shift.

So, any ideas?

Bence

amzipkin

THE CAUSE: Until recently, most Sr isotope data was collected on multi-collector instruments. When iolite would import data from those mass spectrometers, the input channels would mostly have names like 'm87', 'm86' etc. Most quad instruments will name those same channels 'Sr88', 'Sr87' etc.

In the previous version of Sr isotope DRS, the DRS would look for these channels based on mass. Then it would calculate interference corrected channels, one of which would be 'Sr87' (i.e. the Sr87 signal after correcting for the Rb87 interference). When iolite would store the results of this calculation, if there was already an input channel called 'Sr87', it would inadvertently overwrite the input channel. We recently added a check for this happening in iolite v4.5.5, and stopped it from happening (iolite in principle never alters input channels after import). That would be why you're seeing the error.

THE FIX: I have just uploaded an updated version of the Sr isotope DRS to GitHub where those intermediate channels have been renamed to have '_c' added to their name. So, for example, the calculated Sr87 channel is now 'Sr87_c' otherwise, everything else is the same for that DRS.

I hope that helps. If you still have any troubles after updating your copy of the DRS, please let us know.

-Bence

amzipkin

Thanks for the quick fix Bence. The updated version of the Sr Isotopes DRS works with my triple quad ICP-MS data and I see the _c suffix on the intermediate channels.

« Previous Page