Time Dependent Intensity (TDI) Corrections

[John Donovan]

So you would recommend evaluating the models on a point by point basis rather than trying to be consistent with the model used?

Hi Andrew,
I think the model you use to evaluate the fit should be evaluated on a point by point basis since that is how the TDI correction is applied during the matrix iteration.

In your original examples it looked to me (based on the Relative Deviation % displayed) that the log-linear fit gave the smallest avg deviation.
john

[AndrewLocock]

This may have been pointed out earlier, but:

The TDI intensities can be saved in Excel format, and then evaluated in Excel.
An example of Na intensities for a point in obsidian (15 kV, 6 nA, 5 micron beam diameter, nominally 30 s on peak) is in the PDF attachment.

Cheers,
Andrew Locock

[John Donovan]

Hi,

I have a controversial suggestion - to see what you think. Currently TDI only applies to first row elements. This restricts it to the first element on each of the spectromters. I'd like to suggest that it could be used for second row elements - if it was done carefully checking that the intensity was a linear drop of with time - then it can be done for the second row elements. A case were it might be useful is volcanic glass with 2 TAP, 2 PET, and 2 LIF. Where Al is measured after Si (i.e. can't measure Si, Al and Na in first row). Currently you have to make sure its stable for the second row Al, so having to make sure Al is linear drop off is not much harder?

Ben

I saw this old post looking for something else and realized that I should have mentioned to Ben that one can apply TDI corrections to multiple sample setups (each with 5 elements per sample), then acquire them in the Automate! window and then combine them post acquisition using the Combine Samples into  a New Sample feature from the Analyze! window:

https://smf.probesoftware.com/index.php?topic=40.msg12137#msg12137

That way one can utilize TDI corrections on more than 5 elements in a sample. Be sure to update to the latest Probe for EPMA using the Help menu as we fixed some minor bugs in this method earlier this year.

[AndrewLocock]

That way one can utilize TDI corrections on more than 5 elements in a sample.

But should you do that?

TDI is correcting for the change in intensity over time.
For the first set of elements, measured over time period 1, TDI is correcting for changes in the X-ray emission of the sample and ideally the regression provides data that correspond to "time zero" - the fresh, unirradiated original composition.

If TDI is applied to a second set of elements measured at the same spot, starting at time period 2, it will only be able to correct back to the composition of the sample as it was at the end of time period 1 = the start of time period 2.
The second application of TDI on the same analytical point is correcting back to an already-damaged/changed/altered material, not to the original composition.

It may be argued that some further correction is better than none at all, but it must be realized that a second set of TDI corrections during an analytical routine is not a panacea to obtain the actual original composition.

If the sample is sufficiently beam-sensitive that it continues to change during the measurement of a second set of elements,
perhaps a better analytical scheme should be used.

In the case of most zeolite minerals, for which the Fe content is effectively negligible, I find that simultaneous measurement of the 5 main measurable components: Na, Al, Si (all on TAP), K and Ca (both on PET) with a single application of TDI is sufficient.

Cheers, Andrew

[John Donovan]

Yes, of course, you are exactly correct. That is why we don't allow TDI corrections on subsequent elements in the first place!   

But...  and this is what Scott Boroughs does, he will digitize slightly different points for each of these sample setups, so they each get "virgin" interaction volumes.  Of course that assumes that one's sample is homogeneous on the micro scale, but as you say, it's better than nothing.

In a way, this is similar to how the "assigned" TDI correction is acquired. The app "bumps" the stage a specified number of microns for each element and acquires TDI curves for each element separately, which can then be assigned to any subsequent (normally acquired) samples for a TDI correction.

[dawncruth]

One concern that has arisen multiple times by my users is how TDI is affected by the apparent/perceived lag between counting and when the Faraday cup is removed. In other words, does counting happen immediately after the cup is removed and there is simply a lag in the Acquire window display? Or is there really a lag between counting and the cup removal?  If so, how does that affect the TDI calculation?

[John Donovan]

One concern that has arisen multiple times by my users is how TDI is affected by the apparent/perceived lag between counting and when the Faraday cup is removed. In other words, does counting happen immediately after the cup is removed and there is simply a lag in the Acquire window display? Or is there really a lag between counting and the cup removal?  If so, how does that affect the TDI calculation?

There is always overhead on the microprobe communications.  It's something we all have to deal with.

But the TDI acquisition zero time is referenced from the time the faraday cup is removed, not when the counting starts.   So your users do not need to worry.

Note that you can try using different FaradayWaitOutTime values in the [Faraday] section of the Probewin.ini file.  This is the amount of time that the program waits after the faraday cup is removed before counting starts. You might need to start a new MDB to test each different value.

[sem-geologist]

interesting. As for peaksight, spectrometers firstly move to the positions, then beam current is measured, and then counting starts at once the faraday cup is disengaged (Had not noticed any human perceptible delay). I guess the sequence of steps as instruction in machine code are first copied to microprocessor memory and then executed there, at least I would do so. For TDI builtin hardware sequencer rather should be used and not direct commands to count, read, reset and repeat again and again. It should get counts as array binned by set timespan per bin. The same as with mapping, just without moving the stage. Actually I got an idea - in case the probe controll api for TDI do lots of PC<->probe communications, the mapping or (even better) line-crosssection API mode could be overused for this with set length of few nm or 0 (depends if firmware has no "divide by 0" gotchas) - pixels of line will contain equally spaced in timeline counts spaced equally by hardware with no relevant lag or glitch.
Another thought - counting is in hardware (there are 24bit counters implemented in FPGA) if they are reset prior launch (which should take place during initial spectrometer moving to the positions), only a single clock cycle is needed to start them, at 16 MHz the delay will be about 1-2µs which would translate into at most one or two pulse counts missed (in case of over-saturated count rate, but TDI then is the least concern). (FPGA in new gen on cameca electronics work at 50MHz thus delay is rather even more irrelevant). Unless software is micromanaging and sending every command sequentially (Hopefully rather not either with Peaksight and either with PfS).

Just for the record, there is also delay of beam hitting the sample after disengaging the faraday cup due to inductance of the beam and beam control deflectors. It is more visible where beam needs to be deflected to the faraday cup, instead of faraday cup being mechanically inserted into the beam. Thus there could be actually opposite delay - counting being engaged before beam drifts into the right spot.

[John Donovan]

interesting. As for peaksight, spectrometers firstly move to the positions, then beam current is measured, and then counting starts at once the faraday cup is disengaged (Had not noticed any human perceptible delay). I guess the sequence of steps as instruction in machine code are first copied to microprocessor memory and then executed there, at least I would do so. For TDI builtin hardware sequencer rather should be used and not direct commands to count, read, reset and repeat again and again. It should get counts as array binned by set timespan per bin. The same as with mapping, just without moving the stage.

I wish I could have coded it that way, but I had to write TDI code that works for both Cameca and JEOL instruments and JEOL does not have this capability, at least not for non-mapping acquisition modes.

And yes, PFE also performs all necessary instrument functions before removing the faraday cup.  The delay after the faraday cup is removed isn't noticeably long on the Cameca.  But JEOL instruments have another problem which is that the JEOL picoammeter is very slow. So when inserting the faraday cup, we often have to wait up to 2.5 seconds(!) before we can obtain a stable beam current measurement.  This is not a problem at the start of the point measurement, but it can be problematic in the second beam current measurement.

In fact each model JEOL instrument seems to have a slower picoammeter. The 89800/8900 picomameter was actually quite fast, essentially as fast as the Cameca. Then the 8200/8500 was slower often requiring up to 1.5 seconds of delay after removing the faraday cup. And as mentioned above the 8230/8530 picoammeter is even slower.

This is not a problem for the TDI measurement because we're not measuring the absorbed current after removing the faraday cup (unless you are using the measure absorbed current option with TDI!), but if someone is measuring absorbed currents normally and has set the FaradayWaitOut too long (in order to obtain accurate absorbed current measurements), there will be an appreciable delay before the counting starts (if we were really smart we would measure absorbed current during the x-ray intensity measurements- need to think about that!). 

Note that PFE measures the faraday current both before and after each x-ray measurement and can also measure the absorbed current measurement before and after the x-ray measurement (when the faraday cup is removed).

I think the best compromise for JEOL instruments might be to set FaradayWaitOutTime to zero in the Probewin.ini file (for timely TDI measurements), then set the Incubation/Decontamination delay time (in the Acquire! | Acquisition Options dialog) from zero to a couple of seconds when you aren't measuring TDI but need to obtain accurate absorbed current measurements.

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

Or JEOL could provide a faster picoammeter...  maybe one of you electronics geniuses could come up with a fast picoammeter circuit for JEOL instruments?  In other words, why did JEOL slow down their picoammeter so much over the last several decades?

[Probeman]

...then set the Incubation/Decontamination delay time (in the Acquire! | Acquisition Options dialog) from zero to a couple of seconds when you aren't measuring TDI but need to obtain accurate absorbed current measurements.

This feature is shown here:



By incubation time we mean the delay that may be necessary to account for the time is takes for the ion migration to begin after the faraday cup is removed (the interaction volume needs to heat up), though this can be resolved also by simply increasing the beam current.

The decontamination time is the same feature but used to delay the measurement of carbon (again, after the faraday cup is removed), in order to provide time for the beam to "burn off" any surface hydrocarbon contamination when measuring trace C Ka.

[mwloewen]

Apologies if this has been addressed in this thread already--

Have you considered adding a test for regression significance that if not met would turn off the TDI correction on a point-by-point and analyte-by-analyte basis? This was TDI would only be applied if it was statistically justified.

Below is copied from an example of how we do this with time-resolved LA-ICP-MS analyses. It seems like a similar approach would be helpful by EPMA if possible to implement.

https://jlubbersgeo.github.io/lasertram/explanation/

We determine the significance of each regression by evaluating following null hypothesis: there is no relationship between a given analyte's internal standard normalized ratio and time. We reject this if both the following conditions are true: The p-value for the coefficient (i.e., slope) is significant; The F-statisic comparing the regression and observed data is greater than the critical F value. By default, we set the threshold for p-value significance at .01 (i.e., we have 99\% confidence that we can reject the null hypothesis) in an effort to mitigate drift correcting all but the most linear of changes in normalized count rates, but this may be changed by the user. If the null hypothesis for a given analyte is rejected, the analyte is linearly corrected for drift and the regression parameters (e.g., slope and intercept) are used to calculate a normalized count rate for the calibration standard at the point in time where an unknown was analyzed: where is the regression slope, is the analysis time, and is the intercept for analyte .

[John Donovan]

Have you considered adding a test for regression significance that if not met would turn off the TDI correction on a point-by-point and analyte-by-analyte basis? This was TDI would only be applied if it was statistically justified.

Almost everything is possible, given enough time and resources!     

Not a bad idea, we will consider the suggestion.

[Ben Buse]

This is probably esoteric. But what happens when you aggregate tdi elements. Is the tdi applied before or after aggregation and does it have an impact on the resultant error. Does summing two tdi curves each made of noisy data, give you the same answer as summing noisy data and then applying tdi?

[John Donovan]

This is probably esoteric. But what happens when you aggregate tdi elements. Is the tdi applied before or after aggregation and does it have an impact on the resultant error. Does summing two tdi curves each made of noisy data, give you the same answer as summing noisy data and then applying tdi?

No, it's a reasonable question, though one could easily perform an experiment to test these hypotheses.

But to make it easy I can say that, just as is the case for on, hi and lo (and MPB) peak intensities for duplicate elements, "volatile" or TDI intensities are aggregated before any corrections are applied, then the TDI fit is applied to the aggregated intensities. This ensures that counting statistics are propagated naturally through the sensitivity calculations.

Here is the aggregate/fitting code for TDI intensities:

Code Select Expand

Sub VolatileCalculateFitSelf2(txdata() As Single, tydata() As Single, ttdata() As Single, tldata As Long, npts As Integer, tlinenumber As Long, samplechan As Integer, sample() As TypeSample)
' Alternative method to perform self volatile correction using unique line number instead of datarow number (necessary for routine AnalyzeSampleLinesAnalyze).
' txdata() is the number of seconds elapsed (returned)
' tydata() is the cps intensity data (natural log) (returned)
' ttdata() is the count time data (returned)
' tldata is the line number of the data point (returned)
' npts is the number of intervals measured (passed)
' tlinenumber points to unique line number (passed)
' samplechan points to element row array (1 to MAXCHAN%) (passed)

ierror = False
On Error GoTo VolatileCalculateFitSelf2Error

Dim sampleline As Integer, ipp As Integer, chan As Integer
Dim samplerow As Integer, norder As Integer, ip As Integer
Dim i As Integer, k As Integer, m As Integer, lastduplicatechan As Integer
Dim avgdev As Single, tempy As Single
Dim time1 As Double, tempx As Double

Dim acoeff(1 To MAXCOEFF%) As Single

' Set default
sample(1).VolatileFitIntercepts!(samplechan%) = 0#
sample(1).VolatileFitSlopes!(samplechan%) = 0#
sample(1).VolatileFitCurvatures!(samplechan%) = 0#
sample(1).VolatileFitAvgDev!(samplechan%) = 0#
sample(1).VolatileFitAvgTime!(samplechan%) = 0#

tVolatile.VolatilePoints% = 0
tVolatile2.VolatilePoints% = 0

' First check that sample is a self calibration sample (0 = none, 1 = self, 2 = assigned) or an alternating on-off sample
If ProbeDataFileVersionNumber! > 4.83 Then
If sample(1).VolatileAcquisitionType% <> 1 And Not sample(1).AlternatingOnAndOffPeakAcquisitionFlag Then GoTo VolatileCalculateFitSelf2NotVolatileSelfSample
End If

' Get sample row and sample datarow (based on unique line number!)
Call DataGetMDBLine(tlinenumber&, samplerow%, sampleline%)
If ierror Then Exit Sub
If samplerow% = 0 Or sampleline% = 0 Then GoTo VolatileCalculateFitSelf2BadLine

' Load multi-point alternating on-off data for TDI correction
If sample(1).AlternatingOnAndOffPeakAcquisitionFlag And sample(1).OffPeakCorrectionTypes%(samplechan%) = MAXOFFBGDTYPES% Then
    Call DataMultiPointOnOffGetData2(Int(1), samplerow%, sampleline%, samplechan%, Int(1), tVolatile)
    If ierror Then Exit Sub

    ' Load volatile intensity data for TDI correction
Else
    Call DataVolatileGetData(Int(1), samplerow%, sampleline%, samplechan%, tVolatile)
    If ierror Then Exit Sub
    If tVolatile.VolatilePoints% = 0 Then Exit Sub
End If

' Check for duplicate elements that need to be aggregated (returned ip% is not utilized)
ipp% = IPOS8(samplechan%, sample(1).Elsyms$(samplechan%), sample(1).Xrsyms$(samplechan%), sample())
If UseAggregateIntensitiesFlag And ipp% = 0 And MiscIsElementDuplicated2(samplechan%, sample(), ip%) Then
    lastduplicatechan% = 0
    For chan% = samplechan% + 1 To sample(1).LastElm%

    ' Find next occurance of this duplicate element
    ipp% = IPOS7(chan%, sample(1).Elsyms$(samplechan%), sample(1).Xrsyms$(samplechan%), sample())
    If ipp% > 0 And ipp% > lastduplicatechan% Then

        ' Load duplicate element multi-point alternating on-off data for TDI correction (if alternating on/off flag is set, alternating on/off intensities are available for all elements)
        If sample(1).AlternatingOnAndOffPeakAcquisitionFlag And sample(1).OffPeakCorrectionTypes%(samplechan%) = MAXOFFBGDTYPES% Then
            Call DataMultiPointOnOffGetData2(Int(1), samplerow%, sampleline%, chan%, Int(1), tVolatile2)
            If ierror Then Exit Sub

            ' Aggregate the alternating on/off intensities
            If tVolatile.VolatilePoints% = tVolatile2.VolatilePoints% Then                      ' they should be the same if TDI data exists
            For i% = 1 To tVolatile.VolatilePoints%
            tVolatile.VolatileIntensity!(i%) = tVolatile.VolatileIntensity!(i%) + tVolatile2.VolatileIntensity!(i%)
            Next i%
            End If

        ' Load duplicate element volatile calibration data for TDI correction (if available)
        Else
            If DataVolatileCheckSelfData(samplerow%, sampleline%, ipp%) Then                    ' check that TDI intensities are available for this element
                Call DataVolatileGetData(Int(1), samplerow%, sampleline%, ipp%, tVolatile2)
                If ierror Then Exit Sub

                ' Aggregate the volatile intensities
                If tVolatile.VolatilePoints% = tVolatile2.VolatilePoints% Then                  ' they should be the same if TDI data exists
                For i% = 1 To tVolatile.VolatilePoints%
                tVolatile.VolatileIntensity!(i%) = tVolatile.VolatileIntensity!(i%) + tVolatile2.VolatileIntensity!(i%)
                Next i%
                End If
            End If
        End If
    lastduplicatechan% = ipp%                                                                   ' save last duplicate channel loaded
    End If

    Next chan%
End If

' Check for zero or only one points returned
If tVolatile.VolatilePoints% < 1 Then GoTo VolatileCalculateFitSelf2NoPoints
If tVolatile.VolatilePoints% < 2 Then GoTo VolatileCalculateFitSelf2TooFewPoints

' Correct for deadtime and beam drift
For i% = 1 To tVolatile.VolatilePoints%
If UseDeadtimeCorrectionFlag Then
Call DataCorrectDataDeadTime(tVolatile.VolatileIntensity!(i%), sample(1).DeadTimes!(samplechan%))
If ierror Then Exit Sub
End If

If UseBeamDriftCorrectionFlag Then
If Not sample(1).CombinedConditionsFlag Then
Call DataCorrectDataBeamDrift(tVolatile.VolatileIntensity!(i%), sample(1).OnBeamCounts!(sampleline%))
If ierror Then Exit Sub
Else
Call DataCorrectDataBeamDrift(tVolatile.VolatileIntensity!(i%), sample(1).OnBeamCountsArray!(sampleline%, samplechan%))
If ierror Then Exit Sub
End If
End If
Next i%

' Load data into plot array
time1# = 0#
npts% = 0
For i% = 1 To tVolatile.VolatilePoints%
If tVolatile.VolatileIntensity!(i%) > 0# Then   ' skip negative or zero counts

' Calculate point weighting based on VolElTimeWeightingFactor
m% = 1
If UseVolElTimeWeightingFlag Then
Call VolatileCalculateWeighting(i%, m%)
If ierror Then Exit Sub
End If

' Add point weighting to fit array
For k% = 1 To m%
tempx# = tVolatile.VolatileDateTime#(i%)    ' re-load original values
tempy! = tVolatile.VolatileIntensity!(i%)   ' re-load original values
npts% = npts% + 1
ReDim Preserve txdata(1 To npts%) As Single
ReDim Preserve tydata(1 To npts%) As Single
ReDim Preserve ttdata(1 To npts%) As Single

' Calculate elapsed time for calibration data
If time1# = 0# Then time1# = tempx#
tempx# = tempx# - time1#                                                                    ' offset to zero time
tempx# = tempx# * SECPERDAY#                                                                ' convert to seconds
tempx# = tempx# + sample(1).VolCountTimesDelay!(sampleline%, samplechan%)                                           ' add in faraday cup out delay and software latency
txdata!(npts%) = tempx# + 0.5 * sample(1).OnCountTimes!(sampleline%, samplechan%) / tVolatile.VolatilePoints%       ' subtract half the interval count time for proper algebra

' Calculate log counts per sec
tydata!(npts%) = Log(tempy!)     ' take the natural log

' Load count interval time data
ttdata!(npts%) = tVolatile.VolatileInterval!(i%)
Next k%

End If
Next i%
tldata& = sample(1).Linenumber&(sampleline%)

' If no valid data for this line, print warning
If DebugMode Then
If npts% = 0 Then
msg$ = vbCrLf & "WARNING in VolatileCalculateFitSelf2- no Time Dependent Intensity (TDI) self-calibration fit data for " & SampleGetString$(samplerow%) & ", line " & Str$(sample(1).Linenumber&(sampleline%)) & ", element " & sample(1).Elsyms$(samplechan%)
Call IOWriteLog(msg$)
End If

' If only one point for this line, print warning
If npts% = 1 Then
msg$ = vbCrLf & "WARNING in VolatileCalculateFitSelf2- one point Time Dependent Intensity (TDI) self-calibration fit data for " & SampleGetString$(samplerow%) & ", line " & Str$(sample(1).Linenumber&(sampleline%)) & ", element " & sample(1).Elsyms$(samplechan%)
Call IOWriteLog(msg$)
End If
End If

' Perform fit in log space on actual number of points
If npts% > 1 Then
Call VolatileCalculateFitCoefficients(sample(1).VolatileFitTypes%(samplechan%), npts%, txdata!(), tydata!(), acoeff!(), avgdev!)
If ierror Then Exit Sub

' Store in sample
sample(1).VolatileFitIntercepts!(samplechan%) = acoeff!(1)      ' save log intercept for display only
sample(1).VolatileFitSlopes!(samplechan%) = acoeff!(2)          ' save log slope term
sample(1).VolatileFitCurvatures!(samplechan%) = acoeff!(3)      ' save log curvature term also
sample(1).VolatileFitAvgDev!(samplechan%) = avgdev!
sample(1).VolatileFitAvgTime!(samplechan%) = (sample(1).VolCountTimesStop(sampleline%, samplechan%) - sample(1).VolCountTimesStart(sampleline%, samplechan%)) * SECPERDAY#

Else
sample(1).VolatileFitIntercepts!(samplechan%) = 0#
sample(1).VolatileFitSlopes!(samplechan%) = 0#
sample(1).VolatileFitCurvatures!(samplechan%) = 0#
sample(1).VolatileFitAvgDev!(samplechan%) = 0#
sample(1).VolatileFitAvgTime!(samplechan%) = 0#
End If

Exit Sub

' Errors
VolatileCalculateFitSelf2Error:
MsgBox Error$, vbOKOnly + vbCritical, "VolatileCalculateFitSelf2"
ierror = True
Exit Sub

VolatileCalculateFitSelf2BadLine:
msg$ = "Invalid data line number (" & Format$(tlinenumber&) & ") was passed"
MsgBox msg$, vbOKOnly + vbExclamation, "VolatileCalculateFitSelf2"
ierror = True
Exit Sub

VolatileCalculateFitSelf2NotVolatileSelfSample:
msg$ = "The current sample was not acquired using the Self Calibration Time Dependent Intensity or Alternating on/off peak (TDI) Acquisition option. See the Special Options button Or Acquisition Options in the Acquire! window for details."
MsgBox msg$, vbOKOnly + vbExclamation, "VolatileCalculateFitSelf2"
ierror = True
Exit Sub

VolatileCalculateFitSelf2NoPoints:
msg$ = "No TDI intensities were found for data line number " & Format$(tlinenumber&) & ", channel " & Format$(samplechan%) & ". This error should not occur, please contact Probe Software technical support."
MsgBox msg$, vbOKOnly + vbExclamation, "VolatileCalculateFitSelf2"
ierror = True
Exit Sub

VolatileCalculateFitSelf2TooFewPoints:
msg$ = "Less than two TDI intensities were found for data line number " & Format$(tlinenumber&) & ", channel " & Format$(samplechan%) & ". This error should not occur, please contact Probe Software technical support."
MsgBox msg$, vbOKOnly + vbExclamation, "VolatileCalculateFitSelf2"
ierror = True
Exit Sub

End Sub


[Ben Buse]

Thanks John

My next question is how do I extract aggregated tdi intensities. For Fe Flank measurements I have La on two spectrometers, which PFE aggregates, however when I view the graphical display of TDI in PFE and when I export the data using the flank export format I can only see the individual tdi values.

Thanks