Using splines in a DRS

In this post I'm going to give a description of how someone making or modifying a DRS can take advantage of the DRS support functions included in Iolite for working with splines. I'll use the existing "Sr_isotopes_REE" DRS as an example - it's distributed with Iolite, which should make life easy for anyone that wants to use it as a template.
The below image is all of the lines of code required – thanks to Iolite's built in DRS support functions things are kept pretty short and simple…

Before I start on the nitty gritty, there's one important detail that I think is important to understand about splines. They are made and updated by the underlying Iolite code, not the DRS. It is possible to prompt Iolite to update splines, but you won't actually be making them in the DRS. Instead, the aim in the DRS is to implement splines that already exist.

So, presumably if you're at the stage where you're trying to use splines you know the basics of editing a DRS, so I'll skip to the particulars. Firstly, you need to make sure that the wave you're interested in has a spline. In order to be splined, your wave has to be in a list of channels, so make sure that you've added it to one, e.g.:

One other thing is worth noting, and that is that only pre-defined standards (i.e., those that pop up in the list of integrations) and the Baseline_1 integration type will be splined. Output_1, and any integration types you make yourself will never get a spline.
Now, to check whether the spline you're interested in exists, you should use the function:

A couple of things are worth noting about the above function. Firstly, it looks only at the integration type that you specify, so it will not consider other integration types (in the above example I've used the Global String from the header of the DRS called ReferenceStandard, but you could put something else in there. like "G_NIST612").
The first thing that the function does is check whether the spline exists. If it doesn't then it will stop the DRS and report in the history window to let you know what happened. If this happens, everything above that line in the DRS will have been done as per usual, but nothing below that point will have been calculated.
If the spline does exist then the function will try to make sure that all other splines for that integration type are properly built and ready to use.

Ok, now that we know the spline we're interested in exists, we need to make it accessible for use in the DRS. The reason for this is that splines can have a variable number of points, depending on what type of spline they are, and the spacing of the points in the wave will not match the spacing of the Index_Time wave. The following function is used to interpolate the spline onto the Index_Time wave, after which it can be used like any other wave in the DRS:

As with the MakeIoliteWave function, you can choose whatever name for the wave that you feel is appropriate("StdSpline_Sr87_86" in this case), just be sure to keep their length <20 characters, as longer than this can potentially cause bugs. Now you have the same spline that you would see in the graph display (e.g., the main control window) available as a regular wave. Assuming that you want to normalise using the spline, the next step is to get a value for your reference standard. You can just hardwire in a value, but if you want to get more sophisticated you can also pull the value from the standard file. This way, as the reference standard is changed, your DRS will automatically use the appropriate value. To do this, you can use the following function:

This line will create a variable with the name you choose ("StdValue_Sr87_86" in this case) and get the value from the standard's text file. Just keep in mind that the name you provide needs to exactly match that in the text file ("87Sr/86Sr" in this case). Ok, now we have all the pieces required, so it's time to make a wave to hold the normalised data:

And do the actual calculation

Now the channel of normalised data is ready, so the final step is to add the new channel to the list of output channels:

All done!

Switching between DRS

The ease with which you can rapidly switch between different elements for internal standardisation and different reference materials for external calibration (see last post) is one of the great strengths of Iolite.

This can be extended to the DRS level too. If, for example, in addition to standard U-Pb geochronology, you wish to do some trace element analyses simultaneously on your zircon/monazite/etc grains this is straightforward. Just make sure that, during the analysis routine, in addition to the 91500 zircon (or whatever your favourite calibrant may be) you include a NIST glass or other reference material for the trace element calibration. Also, of course add an internal standard element such as Si to your zircon run routine in addition to any trace elements of interest.

Then, when it comes to crunching the data just use the U-Pb DRS as normal to process the analyses for age and export the data (the U-Pb DRS will ignore all the other information collected - it is only interested in the stuff required to do its own particular job). Then you can just switch to the Trace_Elements DRS and reprocess the data again for trace element abundances using the NIST glass as reference and Si as internal standard. These data can also be exported as usual.

You can save each 'process' as a separate experiment so it will be easy to go back and forth if you need to check anything or adjust parameters.

Those doing simultaneous U-Pb and Hf isotopes on MC-ICPMS should be able to do a similar thing i.e switch between U-Pb and Hf isotope DRS..

Benefits of the Trace Elements_IS DRS

Those new to Iolite will notice that there are two version of the Trace elements DRS, called simply Trace_Elements and Trace_Elements_IS. Which one do I use?

Well, if you are analysing a whole bunch of samples with similar major element composition (e.g. speleothems or corals where you can reasonably expect stoichiometric behaviour), or you are simply doing a laser traverse or map you just need a fixed internal standard value, say 0.4004 for Ca (this is in fact the default setting ). For this you can use the Trace_Elements DRS and, if necessary, change the IS value in 'edit settings'. Your final export data will be reported relative to this value.

However, let's say that you have a whole bunch of pyroxenes or feldspars to analyse. You can still use the Trace_Elements DRS but it is likely that the Ca content will be slightly different for each mineral grain that you analyse. You could export and then play around for an hour or so in excel trying to make everything right but the far simpler solution is to use the Trace_Elements_IS routine.

Ideally you would set your samples up on the electron probe and determine the major element compositions and then transfer the digitised coordinates to your laser system to ablate the same spots. This should then give you a different (but correct) internal standard value for each laser spot analysis. Now...to processing.

Once you have selected the Trace_Elements_IS DRS, and selected baselines and standards, everything proceeds as normal but when you hit the 'Crunch' button you will be presented with a new window:

This Trace Element Control panel has a number of buttons. Pressing 'Export Sample Name Table' will generate a template in to which you can enter all the internal standard data (for multiple elements if required) for each sample - this is then re-saved as tab-delimited text.

You can load this file back in to Iolite using the 'Reload Int Std Info' button and choosing this file. Now results for each sample will be calculated according to the IS values contained in the table and using the element specified as the Internal Standard in the 'Edit Settings' dialog. The 'Show Int Std data' button can be used to view the IS data in current use - note all values in these tables to be in wt% element.

That's pretty useful - we are now using different IS values for each grain BUT what if you have a whole bunch of different minerals and you need to use different elements as internal standard for each mineral? This is also straightforward.

After exporting data for some minerals (let's say cpx and plag using Ca as internal std) we then simply recast the experiment with a different internal standard (let's say Ti since we want to process some titano-magnetites) and using a different calibrant with higher Ti content than the NIST 612 that we used for the plag and cpx.

First, in the 'Active Integration Type' drop-down we can choose another calibration material - in this case 'G_BCR2G' (in the absence of an opaque oxide reference material this is a good choice of calibrate since it contains a reasonably high and well defined level of Ti). Then we simply add a few BCR2G integrations from the dataset. Now go in to 'Edit Settings' and change the Index Channel to 'Ti49', and Reference Standard to 'G_BCR2G' . Saving these settings should bring up the Trace Element Control Panel once more and you can now see that Ti is being used as the internal standard and the calculated results are now referenced to BCR2G. The oxide data should now be much more realistic than when you crunched the data with Ca as internal std and can be exported as usual.

So, it should be possible to process multiple minerals using multiple internal standard elements and multiple values for these in a relatively short period of time.

Newly published Iolite article

As Jon mentioned recently on the forum, a paper detailing much of Iolite's functions and features is now available as an Advance Article at JAAS.
The article describes the main features of Iolite, and provides details of the main processes of data reduction (including how statistics are calculated).
There is also an online supplementary info file that contains more detailed information about data folder structure, and a detailed description of the format of different waves in Iolite.

If you're unable to get hold of a PDF directly then feel free to email one of us and we'll send you a copy...