Author Topic: Bruker metada in spx and defined detector in DTSA-II discrepancies.  (Read 1159 times)

sem-geologist

  • Professor
  • ****
  • Posts: 304
I am opening new thread so that thread would be dedicated on one simple problem. While I see very nice results with DTSA-II for high energy lines, there are some simulation and quanti issues at low energies, and so I am trying to identify the possible problem. When defining detector in the DTSA-II I had used importing of metadata from spectra, and used some representative (that is same conditions, configuration of pulse counter, and geometry) spx spectra for that. However when I try to simulate spectra for that detector for known phase, I get quite huge discrepancy in intensities at low energy region - simulated intensities at low energy is higher than measured. I had saved DTSA-II defined detector as xml, and inspected it and see that detector and window composition information described were not used fully. Moreover DTSA-II allows to choose detector window from predefined list, and I thought that Moxtek AP 3.3 is synonymous with "SLEW AP 3.3" which is listed in the spx. Some of the properties differ, the Moxtek defined by DTSA-II has only two elements (composition of support grid is not defined), while spx description of detector window layers contain 6 elements, where the last layer have relative area provided, thus I guess it is support grid ( the relative open area and thickness agrees exactly with that of 'moxtek (modified table)'; the Al layer in spx description has 35.0, while in DTSA-II moxtek description 30.0; however moxtek does not list i.e. C which in spx window description takes even 145.0. The detector layer description in spx (which is BTW zlib compressed and base64 encoded from prying eye, but not from seasoned reverse-engineer like me) is a bit confusing, as layers does not sum-up to given 0.45 thickness of the detector. I guess that is due to Si not listed in the layers of detector, so the missing thickness between sum of other layers and total given thickness of detector is Si layer, but I can be wrong.

So is there a way to make the descriptions to agree inbetween spx and that DTSA-II defined? Is it possible to add detector composition information to the detector description? I would not mind to edit xml.
« Last Edit: April 07, 2021, 01:10:08 AM by sem-geologist »

sem-geologist

  • Professor
  • ****
  • Posts: 304
Re: Bruker metada in spx and defined detector in DTSA-II discrepancies.
« Reply #1 on: April 07, 2021, 01:05:54 AM »
in particularly this is a bit confusing:

<SpectrumProperties>
        <null/>
        <int>21</int>
        <string>Aluminum layer thickness</string>
        <double>35.0</double>
        <string>Aluminum window thickness</string>
        <double>30.0</double>
        <string>Azimuthal angle</string>
        <double>0.0</double>
        <string>Dead layer</string>
        <double>0.029</double>


Does "Aluminum layer thickness" is total thickness? or only thickness in detector (without window).
Aluminum window thickness is later listed under leaf of detector window xml branch. Which one is taken in consideration/calculations?
so If I would want to add carbon, boron, I should add tag <string>Carbon window thickness</string> followed by <double>value</double>. Would that work?

sem-geologist

  • Professor
  • ****
  • Posts: 304
Re: Bruker metada in spx and defined detector in DTSA-II discrepancies.
« Reply #2 on: April 07, 2021, 01:14:14 AM »
BTW, azimuth angle is completely irrelevant, as spectra is sum from two EDS detectors. Interestingly Bruker gather spectras separately and API allows to have different pointers for acquired spectra, but GUI of Esprit stick all into single spectra, and spx contains single azimuth - which is irrelevant in that case. As there is no sample tilt, and both unknown and standards are measured at same geometry and conditions, this probably can be safely ignored. This rather have no direct impact to the Low-high energy intensity discrepancies described above.

sem-geologist

  • Professor
  • ****
  • Posts: 304
Re: Bruker metada in spx and defined detector in DTSA-II discrepancies.
« Reply #3 on: April 07, 2021, 05:24:45 AM »
to spill some fuel on my confusion, I had realized that in GUI in that table of spectra atributes detector layers are rightly filled. So detector xml file (xdet) is filled with something else... and I had realised that in .xdet file the xml node for window is called "XRayWindow2", so does it mean that DTSA-II applies double window correction, one read from file, and other from the spectra?
« Last Edit: April 07, 2021, 05:29:39 AM by sem-geologist »

Nicholas Ritchie

  • Moderator
  • Professor
  • *****
  • Posts: 155
    • NIST DTSA-II
Re: Bruker metada in spx and defined detector in DTSA-II discrepancies.
« Reply #4 on: April 07, 2021, 05:30:11 AM »
The detector model is important for simulation but much less so for quantification.  The only parameters that really matter for quantification are the detector energy scale, resolution and visible elements by line family.  Choice of windows model doesn't matter for quantification.

Simulation of low energy X-rays is very difficult and quantification of low energy X-rays is fraught.  The physics of low energy X-rays is poorly known so the models are crude.  DTSA-II does the best it can with the best physics I can find.  My suggestion is to pick a window that works ok and stick with it.  It really isn't going to make that big a difference.  If you are really persistent however there is a method to enter a CSV file containing the detector efficiency as  function of energy.  This is mainly intended for situations in which this data has been measured on a synchrotron.

Quantification of low energy K-lines (like O K) usually works ok but with good precision but poorer accuracy.  Quantification of low energy L-line is total hit or miss.  Basic assumptions built into the matrix correction models fail for many period 4 transition metals.  M-lines are likely to be almost as bad as L but for different elements.

I have the same issue with multiple detectors and azimuthal angle.  The azimuthal angle is mainly important for Monte Carlo simulation of complex geometries where it actually matters where the detector is located in 3-space.

If the xdet file generated in the Preference dialog doesn't match the detector definition in the Preference dialog this is a different issue.  Please provide screenshots of the full detector preference page and the associated xdet file so I can debug it.
"Do what you can, with what you have, where you are"
  - Teddy Roosevelt