Author Topic: Detection Limit Map Error  (Read 11587 times)

Aoife McFadden

  • Student
  • *
  • Posts: 4
Detection Limit Map Error
« on: December 15, 2014, 07:36:22 PM »
Hi All,

When exporting the detection limit maps in CalcImage for Surfer presentation I get the following error pop up. Not sure what it means or if its something I've done wrong?

Cheers,

Aoife

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Detection Limit Map Error
« Reply #1 on: December 15, 2014, 07:46:52 PM »
When exporting the detection limit maps in CalcImage for Surfer presentation I get the following error pop up. Not sure what it means or if its something I've done wrong?
Hi Aoife,
I can take a look. You're using v. 10.5.7 of CalcImage?

Can you zip up the project (into a .ZIP file) and attach it, or is it too big?  I have a dropbox if it's too big.

That would be the .CIP, .MDB and the .GRD files.
john
« Last Edit: December 15, 2014, 07:49:06 PM by John Donovan »
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Aoife McFadden

  • Student
  • *
  • Posts: 4
Re: Detection Limit Map Error
« Reply #2 on: December 15, 2014, 07:57:57 PM »
Hi John,

Thanks, I'm using v 10.5.5 so I'll update that now.

It's a little too big to post but I've put it in a dropbox folder here:
https://www.dropbox.com/sh/s90gy8mo95xpoyo/AAD_PjaTYGVq-YOEDamASby0a?dl=0

Thanks,

Aoife

Edit by John: Cool, I'll take a look as soon as I can.  The detection limit calculation is slightly problematic because some pixels are not "appropriate" for this calculation, hence the reason why some of them are displayed as a gray color. I've run the detection limit calculation on many samples with success but that doesn't mean that there are not samples that won't work with the code as it is.

One quick question: I note that your iron sulfide std is off significantly because you are using anhydrite as a std.  Of course you may know that one cannot analyze a sulfide using a sulfate std due to the chemical state peak shift between the two.

You have no unknown data, so may I ask what the unknown sample is?
« Last Edit: December 15, 2014, 08:54:49 PM by John Donovan »

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Detection Limit Map Error
« Reply #3 on: December 15, 2014, 08:55:23 PM »
OK, after taking a quick look at the CalcImage project I see that you are analyzing S and Sr on multiple spectrometers in a calcite/aragonite matrix.

I need to deal with this and I apologize that I haven't already, but CalcImage does not implement the aggregate feature as yet! So, please turn off the aggregate element option and recalculate and you should be fine.  Why? Because the matrix is essentially always CaCO3 so the matrix correction will not be adversely affected by the multiple trace elements.

More in a minute...

In the meantime, please see this topic:

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

Guess what I'll be working on this weekend!
« Last Edit: December 15, 2014, 08:57:12 PM by John Donovan »
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Probeman

  • Emeritus
  • *****
  • Posts: 2856
  • Never sleeps...
    • John Donovan
Re: Detection Limit Map Error
« Reply #4 on: December 16, 2014, 02:46:49 PM »
I'd like to take this project and utilize it as a "teachable" opportunity if that is OK.

The goal seems to be to map trace S and Sr in a CaCO3 matrix, so let me start with some general approaches. First of all, you are gaining a factor of 2 in speed by running the maps using MAN backgrounds, so good for you! But rather than running all 5 spectrometers for S, then Ca and Sr on 4 spectrometers on a 2nd mapping pass, it might be better to simply run S and Sr each on a single large area crystal spectrometer (LPET), along with any other traces such as Fe, etc. and merely specify the matrix as CaCO3 as described here:

http://probesoftware.com/smf/index.php?topic=92.msg523#msg523

Edit by John: Wait, in this case one can't specify a CaCO3 matrix and you are correct. Because Sr is interfered with by Ca, we need to measure Ca to make a quantitative interference correction. Sorry about that!

Now you've lost some geometric efficiency, but reduced the mapping to a single pass. So instead of using such a short dwell time for mapping (100 ms per pixel), it might be better to increase the dwell time to 200 ms or more.

Even better might be to reduce the spatial resolution (do you really need 600 by 600 pixels resolution?) to something lower. By going to 1/2 the resolution (300 x 300 pixels) you gain 4x the speed!

Now some other points: I note that you had the Force Negative K-Ratios To Zero option checked in the Analysis Options dialog.  There may be situations where this is useful, but for trace elements it is generally a bad idea because then you are biasing the data higher when measuring close to zero concentrations by eliminating negative k-ratios. See this discussion for more details:

http://probesoftware.com/smf/index.php?topic=392.msg2104#msg2104

I'm assuming you did this because one of the Sr channels had some bad off-peaks positions which resulted in negative k-ratios. In this case, the better solution is to "Disable Quant" for this channel in the Elements/Cations dialog as seen here (making sure you do this for both the unknowns *and* standards if you intend to use the aggregate feature later on):



Here is the Sr off-peak problem I saw in your run (all elements using PET crystals):

On and Off Peak Positions:
ELEM:     S ka    S ka    S ka    S ka    S ka   Ca ka   Sr la   Sr la   Sr la   Sr la
ONPEAK 61379.0 61370.0 61367.0 61375.0 61395.0 38393.0 78439.0 78433.0 78448.0 78464.0
OFFSET 36.5898 45.5898 48.5898 40.5898 20.5898 6.58594 4.28906 10.2891 -4.7109 -20.711
HIPEAK 63299.0 63290.0 63287.0 63295.0 63315.0    ---- 78988.1 80333.0 78996.4 79052.6
LOPEAK 59459.0 59450.0 59447.0 59455.0 59475.0    ---- 77889.9 76853.0 77899.6 77875.3
HI-OFF 1920.00 1920.00 1920.00 1920.00 1920.00    ---- 549.102 1900.00 548.406 588.602
LO-OFF -1920.0 -1920.0 -1920.0 -1920.0 -1920.0    ---- -549.09 -1580.0 -548.40 -588.70


Which produces this for your Anhydrite standard:

On-Peak (off-peak corrected) or MAN On-Peak X-ray Counts (cps/1nA) (and Faraday Current):
ELEM:     S ka    S ka    S ka    S ka    S ka   Ca ka   Sr la   Sr la   Sr la   Sr la   BEAM
BGD:       OFF     OFF     OFF     OFF     OFF    MULT     OFF     OFF     OFF     OFF
SPEC:        1       2       3       4       5       3       1       2       4       5
CRYST:    LPET     PET    LPET    LPET    LPET    LPET    LPET     PET    LPET    LPET
ORDER:       1       1       1       1       1       2       2       2       2       2
 2201G  235.00   75.91  231.75  173.91  230.80  567.01     .39    -.69     .28     .18  19.997
 2202G  236.27   75.56  230.84  173.49  230.70  568.80     .41    -.94     .25     .26  19.984
 2203B  233.67   74.80  230.22  171.91  231.16  579.54     .39    -.80     .35     .16  19.974
 2204G  235.15   76.82  230.50  174.22  230.10  575.94     .41    -.81     .28     .15  19.965

AVER:   235.47   76.10  231.03  173.87  230.54  570.58     .41    -.81     .27     .20  19.982
SDEV:      .69     .65     .65     .36     .38    4.73     .01     .13     .02     .06    .016
1SIG:      .88     .50     .87     .76     .87    1.36     .05     .03     .04     .03
SIGR:      .79    1.30     .74     .48     .44    3.48     .23    4.41     .44    1.71
SERR:      .40     .38     .37     .21     .22    2.73     .01     .07     .01     .03
%RSD:      .29     .86     .28     .21     .17     .83    2.64  -15.48    6.10   29.29


On an entirely different note, in the MAN fits, it is interesting that the Ti standard sometimes plots above the trend for sulfur Ka but on other spectrometers it does not:



Finally I should mention that there is no need to specify the aggregate mode in PFE unless you have unknowns with significant concentrations of the duplicated elements. If there are trace elements duplicated, the matrix correction will be so little affected that it really doesn't matter. And for standards, the program will automatically calculate the correct standard k-factors even for duplicate major elements.

This is a subtle point because if you analyze the standard in PFE, the program treats the standard as an unknown for the purposes of the analysis and if the standard contains duplicate major elements, e.g., Ca in your anhydrite standard the calculated *unknown* matrix corrections will be wrong because of the duplicate major elements as seen here!

ELEM:        S       S       S       S       S      Ca      Sr      Sr      Sr      Sr   SUM 
XRAY:     (ka)    (ka)    (ka)    (ka)    (ka)    (ka)    (la)    (la)    (la)    (la)
  2201  22.923  22.903  22.810  22.823  23.021  30.648    .116   -.711    .121    .111 191.775
  2202  22.995  22.943  22.938  22.922  22.675  30.746    .121   -.970    .109    .159 191.647
  2204  22.724  22.796  22.894  22.897  22.946  31.122    .122   -.832    .122    .090 191.890

AVER:   22.881  22.881  22.881  22.881  22.881  30.839    .120   -.837    .117    .120 191.771
SDEV:     .140    .076    .065    .051    .182    .250    .003    .130    .007    .035    .122
SERR:     .081    .044    .038    .029    .105    .144    .002    .075    .004    .020
%RSD:      .61     .33     .28     .22     .80     .81    2.69  -15.49    6.21   29.28

PUBL:   23.552  23.552  23.552  23.552  23.552  29.439    n.a.    n.a.    n.a.    n.a. 100.000
%VAR:  (-2.85) (-2.85) (-2.85) (-2.85) (-2.85)    4.75     ---     ---     ---     ---
DIFF:   (-.67)  (-.67)  (-.67)  (-.67)  (-.67)   1.399     ---     ---     ---     ---
STDS:      503     503     503     503     503     511     513     513     513     513

STKF:    .2216   .2216   .2216   .2216   .2216   .3783   .4321   .4321   .4321   .4321
STCT:   234.27   76.41  231.59  173.54  230.34  796.40  155.67   48.17  107.43   77.44

UNKF:    .2216   .2216   .2216   .2216   .2216   .2711   .0011  -.0073   .0011   .0011
UNCT:   234.27   76.41  231.59  173.54  230.34  570.58     .40    -.81     .27     .20
UNBG:      .40     .17     .31     .24     .43    1.50     .25    1.06     .16     .15

ZCOR:   1.0326  1.0326  1.0326  1.0326  1.0326  1.1377  1.0835  1.1461  1.0835  1.0835
KRAW:   1.0000  1.0000  1.0000  1.0000  1.0000   .7164   .0026  -.0169   .0025   .0026
PKBG:   590.48  487.24  749.97  741.20  545.49  381.07    2.59     .23    2.68    2.36

Note that not only is the total wrong (191.7 wt%), but the program cannot get the sulfur concentrations to converge due to the non-physical nature of the problem. See here for more discussion:

http://probesoftware.com/smf/index.php?topic=244.msg1159#msg1159

What is happening is that the program still calculates the correct k-factors for the standard to use in the analytical k-ratio but the iterated matrix correction sees the duplicate elements and therefore calculates the wrong physics when duplicate major elements are present.

Just for reference here is the same standard analyzed as an unknown but with the "aggregate" feature checked in the Analysis Options dialog:

ELEM:        S       S       S       S       S      Ca      Sr      Sr      Sr      Sr   SUM 
XRAY:     (ka)    (ka)    (ka)    (ka)    (ka)    (ka)    (la)    (la)    (la)    (la)
  2201  23.647    .000    .000    .000    .000  29.344    .022    .000    .000    .000 100.022
  2202  23.592    .000    .000    .000    .000  29.433   -.002    .000    .000    .000 100.032
  2204  23.416    .000    .000    .000    .000  29.789    .005    .000    .000    .000 100.219

AVER:   23.551    .000    .000    .000    .000  29.522    .008    .000    .000    .000 100.091
SDEV:     .121    .000    .000    .000    .000    .235    .012    .000    .000    .000    .111
SERR:     .070    .000    .000    .000    .000    .136    .007    .000    .000    .000
%RSD:      .51   .0000   .0000   .0000   .0000     .80  148.85   .0000   .0000   .0000

PUBL:   23.552    n.a.    n.a.    n.a.    n.a.  29.439    n.a.    n.a.    n.a.    n.a. 100.000
%VAR:    (.00)   (.00)   (.00)   (.00)   (.00)     .28     ---     ---     ---     ---
DIFF:    (.00)     .00     .00     .00     .00    .083     ---     .00     .00     .00
STDS:      503       0       0       0       0     511     513       0       0       0

STKF:    .2216   .0000   .0000   .0000   .0000   .3783   .4321   .0000   .0000   .0000
STCT:   942.16     .00     .00     .00     .00  796.40  388.71     .00     .00     .00

UNKF:    .2216   .0000   .0000   .0000   .0000   .2711   .0001   .0000   .0000   .0000
UNCT:   942.16     .00     .00     .00     .00  570.58     .06     .00     .00     .00
UNBG:     1.54     .00     .00     .00     .00    1.50    1.62     .00     .00     .00

ZCOR:   1.0628   .0000   .0000   .0000   .0000  1.0891  1.1841   .0000   .0000   .0000
KRAW:   1.0000  1.0000  1.0000  1.0000  1.0000   .7164   .0002  -.0169   .0025   .0026
PKBG:   611.22     .00     .00     .00     .00  381.07    1.04     .00     .00     .00

Anyway that's it for now. I'll be working on trying to get the "aggregate" feature working in CalcImage this weekend so wish me luck!
« Last Edit: December 16, 2014, 08:18:37 PM by John Donovan »
The only stupid question is the one not asked!

Aoife McFadden

  • Student
  • *
  • Posts: 4
Re: Detection Limit Map Error
« Reply #5 on: December 16, 2014, 03:54:55 PM »
Thanks that's awesome!

Yep it's an aragonite matrix, looking for trace S and Sr. We went to 2 passes, measuring S on all 5 spectrometers because S is in such low levels in the sample but it definitely would be better to do it in one pass since there is some sample damage happening. I'll probably give increasing the dwell time a go instead of using 2 passes  and see how it goes. I'm also just reprocessing the maps now with the Force Negative K-ratios to Zero option turned off and the Sr quant on small PET disabled as suggested.

The point about peak shifting in sulfide and sulfate is interesting - is that still noticeable at low levels of sulfur? I don't actually know whether the sulfur in my sample is a sulfide or a sulfate, though since its a biomineral it's generally assumed to be sulfate.

Also I managed to aggregate the grd files in surfer before loading into CalcImage - was easy enough to do.

Cheers for all the help!

Aoife

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Detection Limit Map Error
« Reply #6 on: December 16, 2014, 04:32:25 PM »
The point about peak shifting in sulfide and sulfate is interesting - is that still noticeable at low levels of sulfur? I don't actually know whether the sulfur in my sample is a sulfide or a sulfate, though since its a biomineral it's generally assumed to be sulfate.

Yes, it can be observed even at the 1000 PPM level. We've done many basaltic glasses and for accurate work characterizing sulfur, it is necessary to "know" the oxygen fugacity in advance (or guess it!) in order to "de-tune" the sulfur spectrometer by the appropriate amount. Basically it is a 10% intensity effect between anhydrite and pyrite (or 30 spectrometer units on an Sx100).

In other words, if your analytical relative accuracy is over 10% at some minor concentration level, you probably don't need to deal with the sulfur peak position chemical shift issue, though of course it's generally easy enough to do so.

However as long as you tune the spectrometer for the actual sulfur peak in your standard and unknown, it really doesn't matter what standard or unknown you have, as the chemical state effect is purely a shift as opposed to a change in peak shape. This is demonstrated in this document I prepared some time ago:

http://epmalab.uoregon.edu/reports/Analysis%20of%20sulfur%20in%20VG.doc

Also I managed to aggregate the grd files in surfer before loading into CalcImage - was easy enough to do.
Awesome.

This should work. You need to have the aggregate intensity flag set in the Analysis Options so the standard intensities get properly aggregated for the unknown mapping quant.
« Last Edit: December 17, 2014, 05:09:12 AM by John Donovan »
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Aoife McFadden

  • Student
  • *
  • Posts: 4
Re: Detection Limit Map Error
« Reply #7 on: December 16, 2014, 10:47:27 PM »
Thanks John

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Detection Limit Map Error
« Reply #8 on: December 18, 2014, 10:35:29 AM »
When exporting the detection limit maps in CalcImage for Surfer presentation I get the following error pop up. Not sure what it means or if its something I've done wrong?
Just FYI, one reason you can get all zero detection limit maps is that you can't take a square root of a negative number. So if your bgd intensities in a map are all negative that is what you will get. How can this occur?  Well it's not easy, but if something is terribly wrong with your background correction for instance...
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: Detection Limit Map Error
« Reply #9 on: December 25, 2014, 04:13:14 PM »
Please see this post for information on the new CalcImage "aggregate" method feature now implemented for quantification of x-ray maps:

http://probesoftware.com/smf/index.php?topic=41.msg2180#msg2180

 8)
« Last Edit: December 25, 2014, 04:35:59 PM by John Donovan »
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Probeman

  • Emeritus
  • *****
  • Posts: 2856
  • Never sleeps...
    • John Donovan
Re: Detection Limit Map Error
« Reply #10 on: December 26, 2014, 05:41:34 PM »
I've just got to show this large quantitative x-ray stage map of the aggregated sulfur photons from all 5 spectrometers of the SXFive in Adelaide acquired by Aoife Mcfadden- look at the 200 PPM level patterns- beautiful!



And just in case anyone still needs convincing, here is the raw data from spectro 1 without the MAN background correction and aggregation:

« Last Edit: December 27, 2014, 10:04:54 PM by John Donovan »
The only stupid question is the one not asked!

Karsten Goemann

  • Global Moderator
  • Professor
  • *****
  • Posts: 228
Re: Detection Limit Map Error
« Reply #11 on: January 01, 2015, 05:45:55 PM »
Haunting! ;-)

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 3304
  • Other duties as assigned...
    • Probe Software
Re: Detection Limit Map Error
« Reply #12 on: May 12, 2020, 01:13:54 PM »
Probeman recently reported that when calculating detection limit maps in CalcImage, some elements would display zero for all pixels as seen here for F and O mapped at 10 keV and 30 nA for 30 msec dwell time per pixel in an AlN sample:



For those who didn't already know, one can calculate detection limit (and analytical sensitivity) maps in CalcImage when you quantify your x-ray maps. Here are some of the calculation options in CalcImage:



Unlike x-ray mapping calibration curve methods, we can do a rigorous detection limit calculation because we perform a complete quantification on each pixel, including deadtime, background, matrix and spectral interferences.  The background intensity is of course necessary for detection limit calculations.

Now why did the F Ka detection limit map work, but not the O Ka map? Well, these maps were corrected using the MAN background correction, which eliminates the necessity of acquiring separate off-peak maps, which can double the map acquisition times. MAN background corrections, explained here:

https://probesoftware.com/smf/index.php?topic=307.0

are wonderful for point analyses but really "shine" for quantitative x-ray mapping because they take about half the time and produce better sensitivity. The full peer reviewed paper on the MAN background correction published in American Minerologist (2016) is available here, for those that want all the nasty statistical details:

https://epmalab.uoregon.edu/publ/A%20new%20EPMA%20method%20for%20fast%20trace%20element%20analysis%20in%20simple%20matrices.pdf

So what is going on the O ka detection limit map?  Well, as explained in the paper, there's the variance on the peak measurement, but also a variance on the background measurement. Now traditionally when using off-peak backgrounds, the calculation is straight forward since we can take the interpolated off-peak intensity and calculate the variance (by assuming Gaussian statistics by taking the square root), because the variance is determined by the continuum statistics. Just as it would be for an on-peak measurement with a zero concentration.

But when we perform an MAN background correction, the variance of the background measurement is not limited by continuum statistics, but rather by the variance of the average atomic number of the sample. And the average atomic number is determined by the concentrations of the major elements.

Think of it this way: if you were measuring trace elements in a known matrix, say SiO2 or ZrSiO4, or pyrite, etc., and you *did not* measure the major elements, but simply specified the matrix by difference or a fixed concentration, well the variance of those major element concentrations are close to zero, and hence the variation on the average atomic number is close to zero, and therefore the variance on the background intensity is close to zero.  8)

If instead we do actually measure the major elements, we still have better MAN background statistics than directly measuring the off-peak intensities, because the variance of the measured major elements is still going to be much better than the continuum statistics.

And in addition of course we tend to utilize MAN intensities using several points on several standards covering the range of average Z we need. So we get excellent sensitivity, and as for accuracy, well, that's what the blank correction is for!  But the accuracy is around 200 to 300 PPM for most cases.  If you don't believe these claims please read the linked paper above. It should explain your questions (the second author was originally a strong skeptic too), but if you still have questions, please reply to this topic.

So anyway, because the MAN background intensity is determined using such a radically different method, than we we do for typical off-peak backgrounds, we also need to calculate the MAN variance differently, because merely taking the square root significantly overestimates the variance of the MAN background intensities.

This involves including the statistics of the MAN fit (which is a much smaller contribution that one would think, but see the paper for the details), but in any case for this calculation we need at least three points (standards) on the MAN calibration curve. Because two points always fits a line!   :)

So the rigorous MAN variance calculation cannot be performed for an MAN curve using only two standards (or God forbid, only one standard!). So for elements with less than 3 MAN standards, we revert to a crude estimate by calculating Gaussian variance on the intensity and then reducing that by 30% since on average the MAN statistics improve by about the square root of two on continuum statistics (think about it).

So what was the "bug" on the oxygen detection limit map? Well when the code routine found that the number of MAN standards was less then three, it dropped out of the routine, but didn't bother to load the alternative calculation!  Bad routine!   >:(

But this is now fixed and the update software is uploaded and ready for you to update using the Help menu in Probe for EPMA (yes, this same detection limit bug was also in Probe for EPMA for these MAN detection limit calculations).  And here now are the detection limits re-calculated with the new code:

John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"