Author Topic: Revisiting Detection Limit Calculations  (Read 8559 times)

Dan R

  • Professor
  • ****
  • Posts: 82
    • GE Research Materials Characterization
Revisiting Detection Limit Calculations
« on: May 09, 2014, 10:16:33 AM »
Hello all,
I am trying to figure out a protocol to achieve ~200 ppm Hf detection limits in a Ni-based metal. The first thing I wanted to do was to establish detection limits with my current method before playing around with beam currents and count times.

The first thing that I did was to check the "calculate single line detection limits" box in PFE. PFE calculated CDL99 = 0.095 wt% (950 ppm). I tried to reproduce the "Single Line" Detection limit at 99% Confidence reported in PFE with excel... however I do not get the same results!

Currently I am using 15 kV, 50 nA with 45 sec peak counting time and 20 sec total background counting times to measure the Hf ma on a PET crystal.

The PFE Help file says that single line detection limits are calculated after Love & Scott (1983):
CDL = (ZAF)*(3/Istd)*sqrt(Ibg)*100
where ZAF is the matrix correction, Istd is the raw counts on the analytical standard, and Ibg is the raw background counts on the unkown.

For my situation, the average ZAF correction is 1.6513. The standard intensity is 98.520 cps/nA (or 221670 total counts at 50 nA and 45 sec) and the interpolated background is 0.377 cps/nA (or 376.7 total counts at 50 nA and 20 sec).

Plugging these numbers into the equation above I get: 1.6513*(3/221670)*sqrt(376.7)*100 = 0.0434 wt% (or 434 ppm).

PFE gives a calculated detection of 0.095 wt% (or 950 ppm) for each single line.

Am I doing something incorrect? Any ideas where the discrepancy lies?

I calculated CDL using slightly different equations (based on Poisson statistics) following the work of Pyle & Spear (2003) and I calculate a CDL of 0.0601 wt% (601 ppm)!!! I like this equation because it takes into account the larger uncertainties related to shorter background times (20 sec total vs. 45 sec on peak).

Does the PFE equation assume that peak and b.g count times are equivalent? For example, if I increase my background count time to 45 sec, I get total background counts of 833.5. Plugging this back into the equation above yields even higher calculated detection limits (0.0645 wt% instead of 0.0434 wt%) when I would expect the counting statistics to improve!!!!

Please let me know if you have any comments or insights!

-Dan

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Revisiting Detection Limit Calculations
« Reply #1 on: May 09, 2014, 10:24:24 AM »
Hi Dan,
Remember you need to de-normalize all intensities to raw counts and the standard intensity is for the pure element standard.

If you put the software into debug mode using the Output | DebugMode menu, you will see all the intermediate steps in this calculation.

Also, here is the actual code I am using:

Function ConvertDetectionLimits2(samplerow As Integer, chan As Integer, tRowUnkCors() As Single, tRowStdCts() As Single, analysis As TypeAnalysis, sample() As TypeSample) As Single
' Calculate detection limit for a single element

ierror = False
On Error GoTo ConvertDetectionLimits2Error

Dim temp As Single

' Default is zero
ConvertDetectionLimits2! = 0#

' Normalize standard counts to pure element counts by apply std k-factor
If CorrectionFlag% = 0 Or CorrectionFlag% = 4 Then
If analysis.StdAssignsKrats!(chan%) = 0# Then Exit Function
stdcps100! = tRowStdCts!(samplerow%, chan%) / analysis.StdAssignsKrats!(chan%)

' Alpha-Factors (calculate alpha k-fac = conc/beta)
ElseIf CorrectionFlag% > 0 Then
If analysis.StdAssignsBetas!(chan%) = 0# Then Exit Function
temp! = (analysis.StdAssignsPercents!(chan%) / 100#) / analysis.StdAssignsBetas!(chan%)
If temp! = 0# Then Exit Function
stdcps100! = tRowStdCts!(samplerow%, chan%) / temp!     ' leave std counts in cps/nominal beam
End If

' Determine background count time for unknown
If sample(1).BackgroundTypes%(chan%) <> 1 Then  ' 0=off-peak, 1=MAN, 2=multipoint

' 0=linear, 1=average, 2=high only, 3=low only, 4=exponential, 5=slope hi, 6=slope lo, 7=polynomial, 8=multi-point
If sample(1).OffPeakCorrectionTypes%(chan%) = 2 Then
bgdtime! = sample(1).HiTimeData!(samplerow%, chan%)   ' high only
ElseIf sample(1).OffPeakCorrectionTypes%(chan%) = 3 Then
bgdtime! = sample(1).LoTimeData!(samplerow%, chan%)    ' low only
Else
bgdtime! = sample(1).HiTimeData!(samplerow%, chan%) + sample(1).LoTimeData!(samplerow%, chan%)   ' all other off peak types
End If

Else
bgdtime! = sample(1).OnTimeData!(samplerow%, chan%)   ' use on-peak time for MAN
End If

' Determine unknown beam current for each element
If Not sample(1).CombinedConditionsFlag Then
bgdbeam! = sample(1).OnBeamData!(samplerow%, chan%)    ' use OnBeamData in case of aggregate intensity calculation (use average aggregate beam)
Else
bgdbeam! = sample(1).OnBeamDataArray!(samplerow%, chan%)    ' use OnBeamDataArray in case of aggregate intensity calculation (use average aggregate beam)
End If

' De-normalize unknown background counts for time and beam
bgdcount! = sample(1).BgdData(samplerow%, chan%) * bgdtime!
Call DataCorrectDataBeamDrift2(bgdcount!, bgdbeam!)
If ierror Then Exit Function

' Take square root to get gaussian standard deviation of background
If bgdcount! < 0# Then Exit Function
bgddevraw! = Sqr(bgdcount!)

' Re-normalize background deviation to cps and nominal beam again
If bgdtime! <= 0# Then Exit Function
bgddevcps! = bgddevraw! / bgdtime!
Call DataCorrectDataBeamDrift(bgddevcps!, bgdbeam!)
If ierror Then Exit Function

' Calculate detection limit (three times the standard deviation of the background)
If stdcps100! <> 0# Then
ConvertDetectionLimits2! = 3# * bgddevcps! / stdcps100! * 100# * tRowUnkCors!(samplerow%, chan%)
End If

Exit Function

' Errors
ConvertDetectionLimits2Error:
MsgBox Error$, vbOKOnly + vbCritical, "ConvertDetectionLimits2"
ierror = True
Exit Function

End Function
« Last Edit: May 09, 2014, 01:36:39 PM by John Donovan »
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Revisiting Detection Limit Calculations
« Reply #2 on: May 09, 2014, 10:38:03 AM »
Here is some sample debug mode output where one can see the intermediate detection limit (single line) calculations:

Line:  135 Intermediate Detection Limits Calculations (nominal beam =  30):
Element/Xray     ti ka   fe ka   al ka   mn ka   mg ka
Bgd Count/Sec     92.3    42.8    38.3     9.5    21.3
Bgd CountTime  1200.00 1200.00 1200.00 1200.00 1200.00
Bgd Beam Curr   100.09  100.09  100.09  100.09  100.09
Bgd Raw Count  369643. 171337. 153321. 37857.3 85223.4
Bgd Dev Raw      608.0   413.9   391.6   194.6   291.9
Bgd Dev Cps    .151866 .103394 .097807 .048601 .072920
Std Count/Sec  56851.0 30643.4 9518.18 4916.84 29279.5
Std K-factor     .5616   .6862   .1159   .4052   .4215
Std Cps @100%  101231. 44656.6 82122.1 12134.3 69459.8
Unk ZAF Corr    1.2628  1.1927  1.6729  1.2236  2.1261

Detection limit at 99 % Confidence in Elemental Weight Percent (Single Line):

ELEM:       Ti      Fe      Al      Mn      Mg
   135  .00057  .00083  .00060  .00147  .00067

Wow! 5.7 PPM, 8.3 PPM, 6 PPM, 14.7 PPM and 6.7 PPM.   Now I know what you all are thinking, that these are really good detection limits, almost too good, but what were the conditions?

How about 20 keV, 100 nA and 1200 seconds on-peak and 1200 seconds off-peaks for a total of 2400 seconds per point!

ELEM:       Ti      Fe      Al      Mn      Mg
BGDS:      EXP     LIN     AVG     LIN     LIN
TIME:  1200.00 1200.00 1200.00 1200.00 1200.00
BEAM:   100.09  100.09  100.09  100.09  100.09


The microprobe is an awesome instrument!
« Last Edit: May 09, 2014, 03:29:03 PM by John Donovan »
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Dan R

  • Professor
  • ****
  • Posts: 82
    • GE Research Materials Characterization
Re: Revisiting Detection Limit Calculations
« Reply #3 on: May 09, 2014, 12:21:25 PM »
Hi John-

Thanks for pointing out the debug feature. Since I used pure Hf metal as the standard, I don't think renormalizing to the pure element standard is a big issue.

However, I've figured out why our calculations differ. PFE must assume that the Peak and BG count times are equal (which they should be for trace analyses, but in my case this was not true since I just wanted to see how a current method performed).

Looking at the output, I can calculate exactly the same CDL99 that PFE spits out if I calculate my Raw Std Peak counts using 20 sec (background time) instead of the actual peak time of 45 sec. This difference results in PFE thinking that total raw counts on the standard was ~104205 when it really was ~234451:

                             PFE Calc   My Calc
Element/Xray          Hf ma          Hf ma
Bgd    Count/Sec      0.40          0.40
Bgd    CountTime     20.00          20.00
Bgd    Beam Curr     50.90          50.90
Bgd    Raw Count     429.01          429.01
Bgd    Dev Raw        20.70           20.70
Bgd    Dev Cps           0.02          0.02
Std    Count/Sec      98.96          98.96
Std    K-ratio             0.97          0.97
Std    Cps @100%   102.36        102.36
Std    CountTime      ?                45.00           
Pure    Raw Count   104205       234451   
Unk    ZAF Corr         1.65           1.65
           
Detection limit at 99 % Confidence in Elemental Weight Percent (Single Line):           
           
ELEM:                        Hf                  Hf
990                         0.099            0.044

Edit by John: Ok, I see your problem. Look at the last line of the calculation:

ConvertDetectionLimits2! = 3# * bgddevcps! / stdcps100! * 100# * tRowUnkCors!(samplerow%, chan%)

The term "bgddevcps!" is calculated from the sqrt of the raw bgd counts. It is then re-normalized to time and beam for constructing the elemental k-ratio in the above expression:

K-ratio = bgddevcps! / stdcps100!

By multiplying this elemental k-ratio by the matrix correction "tRowUnkCors!", and times 100 we end up with weight percent detection limit.

So the calculation is correct- but you had me going there for a little while!   :P

Also, note that you don't need to post a 2nd post to fix a typo, just use the Modify button to edit your posts.
« Last Edit: May 09, 2014, 01:49:20 PM by John Donovan »

Dan R

  • Professor
  • ****
  • Posts: 82
    • GE Research Materials Characterization
Re: Revisiting Detection Limit Calculations
« Reply #4 on: May 09, 2014, 06:44:42 PM »
Thanks John! After thinking about it some more, the k-ratio explanation helps quite a bit. I misunderstood the help file equation and assumed that the raw counts on the standard were total raw counts, not normalized to cps/nA.

Edit by John: I can clarify the documentation on that... OK, see updated Help file screen shot below.

Thinking about it in the following way makes a heck of a lot more sense:
My interpolated background is 0.38 cps/nA; at my conditions this is 0.38 cps/nA*50nA*20sec = 380 counts total.

From counting statistics we get 380 +/- sqrt(380) = 380 +/- 19.5.

Renormalizing this to cps/nA gives 0.380 +/- 0.019 cps/nA.

Detection limits are taken at 3 sigma so a peak at 3*0.019 or 0.057 cps/nA above background would be statistically significant. This k-ratio will be 0.057/Istd (Istd = 98.5 cps/nA).

Multiplying the k-ratio by the ZAF correction (and 100%) converts it to concentration, so I would get 0.096 wt% Hf as my CDL, similar to what PFE spit out (0.099 wt%)!

In the end, I just want to be able to use a nice long wavescan to create some synthetic run conditions to calculate detection limits based on counting statistics... so now I can do that, but I ended up learning (or re-learning) a whole lot more!

-Dan

Image inserted by John:
« Last Edit: May 10, 2014, 11:22:08 AM by John Donovan »

Dan R

  • Professor
  • ****
  • Posts: 82
    • GE Research Materials Characterization
Re: Revisiting Detection Limit Calculations
« Reply #5 on: May 13, 2014, 02:00:27 PM »
One final question about this John...
When aggregating multiple spectrometer intensities... how do you normalize the background deviation back to cps/nA when calculating detection limits?

For example, if you had two spectrometers counting at 200 nA and 30 sec... would you normalize the background devation by 1/200nA*1/200nA*1/30sec*1/30sec or would you only divide by the beam current one time?

Thanks!
-Dan

Probeman

  • Emeritus
  • *****
  • Posts: 2856
  • Never sleeps...
    • John Donovan
Re: Revisiting Detection Limit Calculations
« Reply #6 on: May 13, 2014, 02:40:12 PM »
When aggregating multiple spectrometer intensities... how do you normalize the background deviation back to cps/nA when calculating detection limits?

Hi Dan,
The question is a good one, but is essentially moot because of the manner in which the duplicate channel intensities are aggregated!   8)

When aggregate mode is enabled and duplicate element/x-ray channels are present, the software combines the raw photon intensities for both the background and the peak for both the standard and the unknown. This means that all the normal statistical calculations propagate through the aggregated channel without any special handling!  Very cool, I know!   ;D

Note that the element *and* x-ray must be the same for the aggregate mode (you can't aggregate photons that are different energies!), though the duplicate elements can utilize different crystals, e.g., Ti Ka on PET and LIF.

This means that channels with lower intensities, say LIF, will automatically have less influence on the error propagation (as expected), than a channel with higher intensities, say LPET. 

Also see this post on using the aggregate, blank and alternating on/off peak features:

http://probesoftware.com/smf/index.php?topic=29.0

And also attached below, the PFE data from my Am. Min paper.
The only stupid question is the one not asked!

Gareth D Hatton

  • Professor
  • ****
  • Posts: 51
Re: Revisiting Detection Limit Calculations
« Reply #7 on: May 14, 2014, 08:23:07 AM »
Hi John,

Nice of you to share your raw data with us.  Very interesting to see what xtremes ( ;) ) the probe can go to  8)