Wednesday, November 30, 2011

How to add more globals to a DRS


This is just a quick tutorial to show you how to add more global variables or global strings to a DRS. These globals are useful because they're acessible via the Edit Settings window, which means that people not comfortable with the code can quickly and easily view and modify them (e.g., the "ReferenceStandard" global string). These globals are given a default setting in the header of the DRS, which is used every time a new experiment is opened. If a user decides that they don't want to change the setting in the experiment they're working in then they do this via the "Edit Settings" window.

Below is an image of the header text in the Trace_Elements DRS.

To add a new global is pretty straightforward. First, you need to make a new line in the DRS header - the easiest way to do this is to copy an existing line of the header. Pick a GlobalVariable if you want to store a number, or GlobalString if you want to store text (in most cases you'll want to use a variable).
Put the newly copied line directly beneath the line that says "//**** Any global strings or variables you wish to use in addition to those above can be placed here", like this:
Now change the name to what you'd like to use (make sure it doesn't start with a number, isn't more than 30 characters long, and contains no spaces or special characters), and input your default value (or string):
Now we're done with the header text, and for the next step you'll need to look a little lower in the DRS for these lines:
All you need to do here is add your item to the "NVar" list if it's a GlobalVariable, or the "SVar" list if it's a Global String. Make sure you add a comma prior to your item, and that the name is identical to what you put in the line above (copy and paste is the best way to ensure this). Here's my example added to the list of variables:
Now you're all done. To use the global variable within the DRS just use it like a normal variable, e.g.:
Just note that for the change to take effect in any existing experiments you have you'll need to go to the Iolite menu and choose "Update old experiment" so that the new global gets detected by the system.
And remember, if you want to change the setting for your global, you should do this via the Edit Settings window. The header of the DRS stores the default value, which will only be read in at the beginning of a new experiment.

If you have any questions then just post a question on the forum.




Tuesday, November 22, 2011

Uncertainty propagation - how it works

We've had a bit of interest in propagation of uncertainties in Iolite, so I thought I'd try to do two things in this post and the next.

In this post, I'll have a go at describing our protocol for propagating uncertainties. There is a description of the method in Paton et al. (2010), but I'll give a more detailed description here with more pictures in the hope that it may further clarify it.

Then I'll follow this up in the next post by describing how to implement the protocols. Many people may not realise it, but the functions in Iolite are free for anyone to plug into their own DRS, so I'll outline how to do this, and a few things to keep an eye out for in the process.

Monday, October 31, 2011

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!

Saturday, October 22, 2011

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..

Friday, October 21, 2011

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.


Wednesday, October 5, 2011

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...

Wednesday, September 21, 2011

Estimating laser pit depth using the "Beam_Seconds" channel

We've had a few questions regarding how Iolite estimates down-hole fractionation (in the U-Pb DRS), and several people have also had problems reducing their data because the algorithms didn't work as they should.
So, I figured it might be useful to describe a bit about how the depth is estimated, and more practically to explain how you can tinker with it if you find that the default settings aren't working for you...

Wednesday, August 10, 2011

Iolite vs 2.14

Version 2.14 is now available for download from the Iolite website at www.iolite.org.au

New features in the latest release include:
-All statistical code is now unencrypted and collected in the file "Statistical functions.ipf"
-Fixed a bug that affected the rounding of certain numbers in the Report Window and exported files
-You can now export your results from the Iolite menu item
-Fixed a compile error in the DRS template
-Fixed a bug that cut off the top line in a combined laser log file

we look forward to meeting folks at the Iolite workshop in Prague!

Tuesday, July 26, 2011

Interesting posts

Hi all,

As you may be aware, the Iolite team have been busy working on a new release and the Iolite workshop (August 14th) as part of the Goldschmidt conference.

But the forum has been busy with interesting and important questions asked by users. I recommend having a quick look at these topics:

There's a new feature in the Trace_Elements_IS DRS

Here's a discussion of how ratios are calculated in Iolite

...or how stats are calculated in Iolite

And a nifty tip for manually setting image parameters

Also, Dany Savard, one of the regular contributors to the forum, has added some additional standard files for users to download. But, as Jon says "Ultimately, it will always be up to the user to confirm that the reference material values they are using are the ones that they believe in/wish to use." So please check any files you download before you trust them.

That's all for now, but we'll have a release out in the next few weeks, and there will likely be some more activity around here after the workshop.

As always, if you have any questions, feel free to post on the forum!

Sunday, June 26, 2011

Blog update

Hi, you may have noticed that things have been a little quiet here lately – that's not because we're not doing anything, but because we're busy organising the workshop in Prague. We're also busy getting ready the next release of Iolite, which we expect to have ready in late July. It will contain some great new features for laser imaging, as well as some bug fixes.

If you haven't yet signed up for the workshop on August 14th it's not too late, we still have places left – the cost is 30 € (euro) before July 14th, or 50 € (euro) after that date, see here for details.


Monday, May 2, 2011

Masking your results in Iolite - tips and pitfalls



REMEMBER, masking is on by default! So watch this video to find out how masking affects your data! Included is a brief example of how masking works and how masking can affect your results. Also includes things to look out for when setting mask thresholds. If you have any comments or questions, please post on the Iolite forum at http://iolite.earthsci.unimelb.edu.au/forum/

Tuesday, April 19, 2011

Iolite workshop: registration is now open

(Please note that registration has now closed for the 2011 workshop in Prague)


Hi,
Registration for the Iolite workshop is now open!


Just as a quick reminder (the full original post can be found here), the workshop will be run in Prague on the 14th of August, 2011 (the sunday prior to Goldschmidt). It will be in the Prague Conference Center, which is the same venue as the conference, and will start at 1pm and run for 5 hours. To make life easy for anyone planning on attending both the detrital zircon UPb workshop and our Iolite workshop, we'll be using the same venue, and will follow on directly from the UPb workshop with lunch, then start the Iolite session.


To register, please send an email to Iolitesoftware@gmail.com including the following information:
---Name (and title)
---Institution
---Contact details (unless told otherwise, we'll assume you want to use email address you mail from)
---Any comments or special requests
We will then reply to your email with an invoice and payment details.

Cost of the workshop is 30 € (euro) before July 14th, or 50 € (euro) after that date. The cost is per participant, including lunch and afternoon tea.

We encourage all participants to bring their own laptop, and if possible to install the latest versions of Iolite and IgorPro prior to the workshop (we will have install files with us on the day for those unable to pre-install).

For information about the detrital zircon UPb workshop (including registration) click here.

Thursday, April 7, 2011

Selecting integration periods automatically (Part 2)

As promised, this post will cover the 3rd option of automatic integration selection called "detect from beam intensity". This option allows you to select portions of your data that satisfy up to three different criteria (e.g., where U238 is greater than 10000 counts per second). Because such criteria are independent of how your data were collected (e.g., numerous small files vs. a single large file), the method is particularly useful for sessions that don't include some sort of labelling for each analysis. This first short video demonstrates the basics of the interface using a U-Pb dataset as an example:



So you would have noticed the extra level of feedback in this option, with the graph showing not only the location of each integration period, but also which ones you've selected, and the location of any pre-existing integration periods for the selected integration type.

But there's one other thing about this new option which we think makes it really powerful, which is that in addition to your input channels you can also use intermediate and output channels as selection criteria. This means you can use an isotopic ratio, or even the calculated 206/238 age of an analysis to distinguish between analyses, as this next video demonstrates:



The other benefit of being able to use intermediate and output channels is that anyone who's really keen can make waves in their DRS specifically for assisting in selecting integrations. For example, you could make an intermediate wave that is given the value 0 for all parts of your data that you don't want to select, and the value 1 for time intervals of interest, then use this wave as your selection criterion in the "detect from beam intensity" interface. In this way, you could either come up with discriminating criteria that are more complex than what's provided in the current interface, or just make your life a little easier by, for example, rolling three different criteria into a single wave, so that you don't need to set everything up in the interface every time you use it.

Tuesday, March 8, 2011

Selecting integration periods automatically (Part 1)

For anyone trying to process an even moderately sized dataset, the ability to select integration periods automatically is a huge timesaver. In addition, if you're trying for reproducibility in the way you're selecting each analysis, using an automated approach makes this a lot easier than trying to manually select exactly the same intervals over and over again.

Iolite has several ways for you to select integrations automatically, and these will be the focus of a couple of separate blog posts. In this post, I'm going to show you how to use the "information from import" option, which is most useful for sessions consisting of numerous discrete analyses (either in separate files or within a single file). For those of you acquiring laser log files, you can use the "laser log file" option, and the actual selection of integration periods will be virtually identical to what's presented here (there's a bit of extra stuff for synchronising your laser log file with your acquired data, but I'm not going to go into that here).

If your analyses were all acquired in large files, you won't get much benefit from this approach, but luckily for you we've just added a 3rd option called "detect from beam intensity". It's quite a powerful tool that uses channels from your DRS to discriminate time periods of interest, but it will have an entire post to itself in the near future, so I won't go into it more here...

So now to the main event – I've put together the following video to walk you through the process of selecting integration periods automatically:



Wednesday, February 16, 2011

Iolite Workshop - sunday August 14, 2011

(Please note that registration has now closed for the 2011 workshop in Prague)

We'll be running our first Iolite workshop in conjunction with the Goldschmidt conference in Prague later this year!

[Please note: registration is now open, see here for the latest post with details]

The workshop will be aimed at introducing Iolite to new users, and will focus on everything you need to know to get started processing your mass spec. data with Iolite, including:
--- Importing your data
--- How to get the most out of viewing data in Iolite
--- Using the Report Window and X-Y Plot Window
--- Selecting data and using different interpolation methods
--- The basics of modifying an existing DRS

We intend to make it a very hands-on workshop, with participants working through example datasets on their own laptops, instead of just staring at powerpoint slides and handouts. There will of course still be amazingly stunning slides and mindblowingly brilliant handouts, but the hands-on stuff will be so much fun that they'll just fade into insignificance by comparison...

There will be a bias towards laser ablation data in the workshop, particularly U-Pb zircon geochronology and trace element imaging, but we'll also be covering solution mode ICPMS and TIMS data.

Note also that the workshop is being run in cooperation with the Detrital zircon U-Pb geochronology workshop, and will follow on in the same venue to make it easy on anyone wanting to attend both.

Finally, if you have requests or suggestions for other topics you'd like included in the workshop, feel free to comment on this post, or on our forum.

Wednesday, February 2, 2011

v. 2.13: Iolite's been updated!

We've just released an update for Iolite, so we're now on Version 2.13, this version is compatible with IgorPro version 6.21, but should also work on earlier versions (e.g. 6.12).
The update is available from the main Iolite page (http://www.iolite.org.au/Iolite.html).

Here's a quick run-down of what the new release has going for it (I've started with the most interesting bits for those of you with limited attention spans):

--- We've added a new way of automatically selecting integration periods, which uses thresholds for up to three different channels (e.g. select data where Ca43 is greater than 100,000 CPS and the Mg24_v_Ca43 ratio is less than 0.15). This is quite a big feature, and will be the subject of an upcoming post, so I won't go into more details here.

--- The Report Window now quotes all numbers to the equivalent of two significant figures in the uncertainty (e.g. 123.4567 ± 1.23456 will be expressed as 123.4 ± 1.2).

--- The "Auto Y axis" buttons now have a toggle functionality - click them one and the axis will autoscale to encompass all data - a second click immediately after this will do a more clever autoscale which attempts to reject extreme outliers.

--- You can now use shortcuts to get to the Report Window and XY Plot Window using Command+4 and Command+5, respectively (Control instead of Command on PC). These are in addition to the pre-existing shortcuts for the Main Control Window, Traces Window and Log Window using Command+(1,2,3).
--- When selecting the Primary channel, the popup is sticky (i.e. it will have the current item selected when you open the popup), making it easier to systematically move through your channels one at a time.
--- We've added a default setting for whether to add to, or overwrite, existing integrations in automatic integrations windows.
--- There were some cosmetic issues for the Main Control Window on the PC that have been improved.
--- We've fixed a bug on the "Drive L/R" control on the PC
--- People running the newest version of IgorPro (6.21) were getting a bug when trying to create images, which is now fixed.

On top of this there were mountains of small bug fixes, but nothing we need to burden you with here...

Wednesday, January 26, 2011

What do data look like in Iolite?

This is another introductory post for those of you who are new to Iolite and are wondering what we mean when we say that Iolite is all about data visualisation. The video gives you a quick tour of what mass spectrometer data looks like in Iolite.



More specifically, in this video I look at a session about one hour in duration, in which a number of kimberlitic perovskites were sampled by laser ablation. Strontium isotope measurements were acquired (on a Nu MC-ICPMS) at 5 Hz (every 0.2 seconds), with an extended period of gas blank (normal operating conditions, but without the laser firing) at the beginning and end of the analysis. Each spot analysis consisted of approx. 60 seconds of ablation, followed by movement to the next spot position, and a short period of gas blank acquisition. The session consisted of fourteen analyses of sample perovskites, bracketed before and after by three measurements of the 83P13 in-house perovskite standard. If you're really keen on finding out more about the method used,  take a look at http://onlinelibrary.wiley.com/doi/10.1111/j.1751-908X.2007.00131.x/abstract


Friday, January 21, 2011

Using the mouse to navigate your data in Iolite

Here's a quick video demonstrating how you can move around your data in Iolite.



Sorry about the sound quality, I'm working on it!

Wednesday, January 19, 2011

So what does Iolite do?

Iolite has been developed from scratch for processing mass spectrometer data. A key design concept has always been to make the programming as flexible and unrestrictive as possible, so even though it was originally designed for laser ablation data, it's now been expanded to handle solution mode ICPMS analyses and even TIMS data.

The big difference between Iolite and most other software that do similar jobs is the interface – Iolite is designed so that you can deal with your data graphically, instead of looking at columns of numbers in a spreadsheet. This means that you can select time intervals easily with a simple drag of the mouse, and can navigate through your data in a way that just isn't possible with a spreadsheet. On top of that, Iolite is comfortable handling hundreds of thousands of data points, so you can look at a whole day of laser analyses at once.
 
The data processing has a modular design, with a separate data reduction scheme (DRS) for each method used. These DRS' are completely open source, and anyone is free to develop their own, or to modify existing schemes.

We've also put a lot of energy into getting Iolite to do useful things with the data once it's processed, such as making false-colour 3D images from rastered laser data (like the one in the previous post).

There are also features for customising how your data is exported (e.g. for Isoplot), generating reports of the statistics of your sample population, graphing results, propagating uncertainties, and more...

Monday, January 10, 2011

Welcome!

Hello,
Welcome to the Iolite Blog.
Here you'll find regular posts from the Iolite crew across a range of topics. Naturally we will be showcasing new features as they're released, but we'll also post hints and tips on everything from basic user interaction to advanced topics like making your own DRS. We welcome comments to our posts, but would also like to remind you that we have the Iolite forum (http://iolite.earthsci.unimelb.edu.au/forum/) available for in-depth discussions, bug reports, feature requests, etc.