VizualAge UComPbine: 206Pb/238U vs 238U/206Pb

PCarr

Hi all,

I'm having troubles with a signficant difference between 206Pb/238U and 238U/206Pb values, that is to say that these values are not the exact inverse of the other. Most of the time the difference is insignificant, however, on this occasion it is significant and yields ages seemingly too young ages on 238U/206Pb vs 207Pb/206Pb diagram relative to a 207Pb/235U vs. 206Pb/238U diagram as you can see in the QA/QC window image. I've also added a photo of the DRS parameters used.

Has anyone else observed this? and/or have a explanation and work-around?

Regards
Patrick

PCarr

The images above are not super clear, so to clarify the reference material yields an age of 241.1 +- 1.4 on a Tera Wasserburg diagram and 245.2 +- 1.4 Ma on a Wetherill. The data should be normalised to an age of 246.48 +- 0.51.

Joe

PCarr

This is because the 1/(mean of F(t)) is not equal to the mean of 1/F(t). Consider the faked data below:

Here you can see 1/0.4260 = 2.347 does not equal 2.3509. You may want to try changing the stats method in the preferences to use the geometric mean rather than the default.

All the best,

PCarr

Hi Joe,
Thanks for the reply.
So does this mean that the 238/206 values are not normalised to the reference values, but are instead calculated from 206/238 values as above?

When using a geometric mean for normal stats calculation many of my analyses with low signals on Pb isotopes are now below background.

Is it possible to take the output 206/238 values and inverse them manually to produce my 238/206 values? Will my rho values for 238/206 vs 207/206 still be valid?

Regards
Patrick

Joe

PCarr

Yes, at the moment the 238/206 is calculated from the 206/238 values and isn't itself normalized to the reference value. You can change this by running the script below:

F38_6 = data.timeSeries('Final U238/Pb206')
RM6_38 = data.referenceMaterialData('Z_91500')['206Pb/238U'].value()
RM_spline = data.spline('Z_91500', 'Final U238/Pb206')
F38_6.setData((1./RM6_38)*F38_6.data()/RM_spline.data())
data.updateResults()

In my very quick test with a sample size of 1, this does seem to be an improvement. It does not seem to appreciably change the rho values, but you'll get the new rho values anyways since it will be recalculated from the updated Final U238/Pb206 data.

Please let me know if the above improves things for you. It would be a trivial change to have this incorporated into the DRS.

All the best,

PCarr

Hi Joe,

Works great! Thanks for this solution.

Patrick

antony_burnham

"It would be a trivial change to have this incorporated into the DRS"... just wondering if this was incorporated into the DRS in the end.

And does this issue of not normalising U238/Pb206 to the reference material also affect the normal U-Pb Geochronology DRS (a big issue for those of us who prefer to use Tera Wasserburg for plotting data!)?

Also another modification to the VizualAgeUComPbine DRS - one of our students had an issue a while back that the DRS wasn't accounting for different dwell times on 207Pb and 206Pb, causing the ratios to come out wacky. You provided her with a Python script to address this but again I wonder if it was fixed in the DRS during a subsequent update to Iolite?

Bence

Hi antony_burnham

Just regarding the accounting for different dwell times in the DRS: typically people export CPS values from their mass spec, rather than raw counts, and so we don't see this issue very often. Obviously the latter will result in incorrect ratios because it's missing a key piece of information (the dwell time info).

If for some reason you're stuck using the raw counts version, we can incorporate this fix in the DRS. Please let us know.

Kind regards,
-Bence

antony_burnham

Hi Bence, the ANU lab has been using Counts (not CPS) for over 10 years so there's a lot of legacy data in that format. If it's not too much trouble to add an option to the DRS then that would be a helpful addition. I will ask the lab manager if he knows a reason not to use CPS from now on, though.

Also, do you know the answer to whether the UComPbine DRS was updated to normalise U238/Pb206 to the calibration RM? And whether the Geochronology DRS normalises U238/Pb206 to the calibration RM?

Cheers
Antony

Bence

antony_burnham

Regarding the conversion to CPS data, instead of adding it to the DRS, it might be easier to run a simple python script after importing your data. You can copy the code below and paste it in to a blank text file, and save it as something like "dt_corr.py". You can then open it in iolite's Python Workspace and click run (after importing your data) and it'll convert it to CPS data. You can edit the dwell times in the script (second line) to match your setup. Just make sure that the dwell times are in the same order as the channel names (first line).

ch_names = ['Pb206', 'Pb207', 'Pb208', 'Th232', 'U238']
dts = [0.01, 0.02, 0.005, 0.03, 0.01]

for ch, dt in zip(ch_names, dts):
    c = data.timeSeries(ch)
    d =c.data()
    d /= dt
    c.setProperty('Units', 'CPS')
    c.setProperty('Dwell time', dt)

Please let us know if you have any troubles with it.

Regarding the std corrected U238/Pb206 ratios: I have added it to the geochron and UComPbine DRSs. The change will be available in the next release. After updating, please let us know if you spot any issues.

Kind regards,
-Bence

Bence

Just an update on the std-corrected 206/238 ratios: these are not going to be available in UComPbine as the reference materials used for this approach should (and usually do) have variable Pb/U ratios. There is now a DC 238/206 channel that is the inverse of 206/238 to avoid the issues associated with mean-of-ratios vs ratio-of-means. This will be available in the next version of iolite (v4.8).

-Bence

HuiqingHuang

Hi Bence,
I get this error message after the upgrade to v4.8. And I don't get 238U/206Pb ratios in the output.

Also, I find that Iolite4 gets a lot slower after the recent upgrade. Why is that?
I have been aware of the problem Patrick noted. I found the problem matters more when the cps is lower. Cassiterite generally has lower U content, so requires the LA-ICP-MS to be optimized for the analysis.
Cheers,
Jeffrey

Joe

HuiqingHuang

I believe this was fixed in v4.8.1 as per the release notes:
https://iolite.xyz/appcast/mac/release_notes.html

In what way are you finding it slower? Do you know which version you updated from? You can always downgrade to earlier versions if there is a bug preventing you from completing an earlier workflow: https://iolite.xyz/appcast/.

All the best,

HuiqingHuang

Thanks Joe. I just updated to v4.8.2 and can see the problem is fixed.
It was from v4.6 to v4.8.0, I think. Now it gets faster again on v4.8.2.
Also thank you for the link to earlier versions.
Jeffrey

lemonntrii

Is it possible to take the output 206/238 values and inverse them manually to produce my 238/206 values? Will my rho values for 238/206 vs 207/206 still be valid?

teatv apk
download apk