Home Forums UPb Geochron DRS No Values for Pb/U ratios in output file?

This topic contains 3 replies, has 2 voices, and was last updated by  Jeffrey Marsh 3 years, 4 months ago.

  • Creator
    Topic
  • #5191

    Jeffrey Marsh
    Participant

    HI All,

    For a recent processing of U-Pb data collected from an Element2 ICP, the output file has a significant number of lines for Pb/U ratios and associated uncertainties that show either No Value or NaN. All the Pb/Pb have values (incl. 207/206 ages), as do the U and Th concs, so it appears that theres something wrong with calculating 238U/xPb for some integrations. I get the same results with the U-Pb3 and VizualAge DRS, and also with the Iolite v.3 I recently installed. When I look at the signal for those integrations with the No Value/NaN they don’t look any different than the ones that have all the values (as far as I can tell).

    Anyone every had this problem or know what might be causing it?

    I’m running on Windows 7, Igor 6.37, Iolite 2.5 & 3.x

    Thanks in advance for any advice

Viewing 3 replies - 1 through 3 (of 3 total)
  • Author
    Replies
  • #5205

    Dr Bence Paul
    Keymaster

    Hi Jeffrey,

    It’s not entirely clear why you’re not getting U/Pb results, but the first place I would look is at the History/Command Window (Cntl+J). It should show any error messages or issues iolite had with processing your data.

    If there’s nothing there, I would check Beam_Seconds channel to ensure it has a nice saw-tooth appearance and to ensure it doesn’t reset during any of your analyses (in this check and all the following, I refer to checking the time-series data in the Reference Materials and Samples Tabs).

    Then I would look at the raw_206_238 channel: are you getting ratios of any sort there? If so, I would then look at the DC_206_238 channel: do they have values and are they flat? If so, you know that your downhole correction is working.

    Then I would look at your final_206_238 ratio: are there values and do they appear reasonable? If there are no values, check that the standard file you have used has 238/206 ratios in it (although you should have received an error message if that wasn’t the case).

    Please let us know if any of those steps are missing data etc.

    Best regards,
    Bence

    #5265

    Jeffrey Marsh
    Participant

    HI Bence,

    Thanks for the suggestions. Yeah, sure enough, the integrations with the missing values on the output don’t have a signal for Beam_Seconds, DC_206_238, or Final_206_238. They do have relatively regular-looking Input 206 and 238 and raw_206_238 signals, and all of the channels for all the other spots look normal (eg. sawtooth Beam_Seconds). The downhole fractionation curves look similar to the ones i’ve had in the past, with a Gaussian type distribution without any cropping. The Standard is GJ_1 and the file has 206/238, 207/235, 207/206, and 208/232, but doesn’t have any ratios with 204 (not shown in Jackson, 2004). In looking through the raw values and ratios for the problem integrations, it is hard to see anything systematic but I will keep looking.

    Let me know if you have any thoughts.

    #5277

    Jeffrey Marsh
    Participant

    I’ve been trying different Beam Seconds settings in the DRS window, following some of the blog posts on the different methods. The problematic outputs mentioned above were calculated using Rate of Change (as I have always used), with all other settings as default as well. Anyway, I can solve the immediate problem by changing the method to Gaps in Data, which gives a Beam Seconds channel and output values for all the channels for all integrations (and essentially the same values for the one that were calculated by the Rate of Change method initially).

    There is some weirdness, that i’m not sure about: 1) The Beam Seconds start at the pre-ablation spike, not the beginning of the full ablation period. Correspondingly, the Downhole Fractionation curve is blank until ~30 seconds (the amount of time after the pre-ablation triggering of each spot file). I thought I could fix this by changing the Beam Seconds sensitivity to 30, but this yields error messages and only a few ugly looking DHF curves. 2) The Beam Seconds signal does not form a continuous sawtooth pattern, but a series of unconnected forward slashes spanning the ~120 seconds of the total analysis.

    Anyway, it appears to not be a problem, but I am not sure it is the best way to do this.

    Background Info: Each spot/analysis is ~126 seconds long in total (deep depth profiling), and the time series is composed of separate files triggered at pre-ablation (PA).
    So it’s something like: PA -> 30 sec. background -> 60 sec. ablation – >35 sec. background.

    If anyone know the best way to set up a Gaps in Data methods for this setup I would appreciate the advice.

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.