Introduction
Since its introduction in 2007, DTSA-II [Reference Ritchie1, Reference Ritchie2, Reference Ritchie3] has been adopted by numerous researchers, and it has been integrated into numerous educational programs. This is the first of a series of articles in Microscopy Today that will appear in the upcoming months to provide an introduction to use of the product. These articles also will provide details of how DTSA-II can be used to implement best practices for microanalysis in your laboratory or in your teaching environment. These articles will demonstrate how to form the most accurate type of spectrum quantification—standards-base quantification—as well as how to use simulation to optimize various types of measurement problems. They will focus on using DTSA-II to understand the physical process including the interaction of energetic electrons with your sample and the propagation of x-rays through matter and to the detector.
DTSA-II provides many different tools, but the primary ones are for quantification, simulation, visualization, and manipulation of energy-dispersive x-ray spectra. Each of these tools will be introduced separately in forthcoming articles. The remainder of this article will provide an overview of the tools and introduce two important aspects of the program: (1) The way DTSA-II implements detectors for both quantification and simulation and (2) the way DTSA-II imports spectra from disks.
Development of DTSA-II
NIST DTSA-II is a software tool for quantifying and simulating electron-excited energy-dispersive x-ray spectra. It is being developed within the Surface and Microanalysis Science Division at the National Institute of Standards and Technology and is freely available to all from http://www.cstl.nist.gov/div837/837.02/epq/dtsa2/index.html. You are encouraged to download, install the application and follow along. In subsequent articles, example spectra, scripts and other data files will be made available for download to supplement the print content.
DTSA-II was inspired by the original Desktop Spectrum Analyzer (DTSA) (see Figure 1) developed at the National Bureau of Standards (forerunner of NIST) and National Institute of Health by Chuck Fiori, Bob Myklebust and Carol Swyt-Thomas [Reference Fiori, Swyt and Myklebust4]. Following its introduction in the late 1980s the original DTSA developed a cult following in the microanalysis field. The original DTSA only ran on older generations of Apple Macintosh computers (pre-OS 9) with 680X0 and PowerPC processors. When Apple stopped making these in the late 1990s, many researchers held on tight to these aging computers. Many started to ask, when would DTSA be updated? When would there be a version for Windows/OS X/Linux? Was this the end of the line?
Figure 1: A screen shot of the original DTSA program overlaid with childhood pictures of the three authors.
I was familiar with DTSA when I joined NIST. When I worked for an instrument vendor, we delved into DTSA's source code to jump-start some of our own product development. We had gone so far as to print out the source code. As I recall, it filled six three-ring binders. Over the years it had grown into a product that served a number of communities that were too small or too poor to interest the commercial vendors. DTSA was innovative and is sorely missed by many.
Around 2005 it was clear that the time was ripe to revisit DTSA. A port of the code from Mac to PC had been discussed. However this was easier said than done. The code mixed algorithms with user interface code. It was written in a Mac-specific dialect of Pascal, a language that is much less popular on the PC. There were many aspects of the program that were beginning to show their age.
Instead we decided to take the best ideas from DTSA—algorithms, data, simulation, low-level tools, and many others—and to reinvent it from the ground up. I decided to separate algorithms from user interface code. This facilitates reusing the algorithms for other purposes in other programs. I wouldn't limit myself to one operating system. The reinvention would use the most robust multi-platform development solution available—Oracle Corporation's (formerly Sun Microsystem's) Java platform. As a result DTSA-II runs and looks like a native application on many generations of Windows PCs, Apple OS X from version 10.5 and most Linux distributions from the last few years, Solaris, and even a few Unix distributions. DTSA-II is regularly tested on Windows XP, Windows 7, OS X, and Ubuntu Linux; it behaves substantively the same on each.
Finally, like the original, we would make the source code available to all. There are many reasons this is valuable. I hope others will benefit from being able to study the code like I did with the original. Furthermore many believe that it is important that the algorithms we rely on to process our data should not be black boxes. Whether or not we ever decide to look, it should at least be possible to open the box and peer in. Most of the algorithms in DTSA-II are documented in journal articles (which I typically reference in the source code). Quite often it takes pulling together many journal articles to implement a single algorithm. Sometimes the articles leave important implementation details ambiguous, and occasionally there are even errors in the text. As a result “correct” implementations from different researchers may produce subtly different results. Computer source code is the closest thing we have to an unambiguous method to document an algorithm implementation.
Out of respect for the original product, I decided to call the result DTSA-II, although the acronym no longer stands for anything. The versions are labeled with the name of an astronomical object selected in alphabetical order. The current release is called “DTSA-II Deneb” after the brightest star in the constellation Cygnus and represents the fourth release using this naming scheme.
Conventions
For ease-of-use, DTSA-II adheres to common user interface conventions (see Figure 2). One that the program uses extensively is the “right mouse click” convention to pop up a context-sensitive menu. (On Mac OS X computers with a single mouse button, the menu can be accessed via “control click.”) Many global actions can be accessed through the main program menu. Actions that involve the contents of one control are often implemented in a context-sensitive pop-up menu. For example, two different context-sensitive menus are available in the spectrum display window: one displays when the cursor hovers over highlighted regions, and the other displays elsewhere. Many other windows such as the spectrum list and the command window also have context-sensitive menus.
Figure 2: A screen shot of DTSA-II as it looks on Ubuntu Linux. The top half of the application window includes a spectrum display control for viewing and manipulating spectra. The bottom half contains utility tabs. The tab currently being displayed is the “Spectrum” tab. It contains a control to select the “Default Detector,” a list of available spectra, a summary of the properties that the selected spectra hold in common, the KLM selection control, and the composition report. The “Report” tab contains a report in HTML that details the current analysis session. The “Command” tab is a Python syntax command line interface for spectrum math, scripting, and other advanced uses.
Another common convention used regularly by the program is the “wizard-style” dialogs to lead the user through multi-step operations. In a nod to the program's mascot, the little green alien, the dialogs are called “aliens” rather than “wizards,” however they operate in a similar manner. Figure 3 shows one page in the “quantification alien” the tool that steps through the standards-based quantification process.
Figure 3: DTSA-II makes extensive use of a “wizard-style” interface, which steps the user through more complex operations. This figure shows one page in the quantification process on Apple OS X. There are other wizards for simulation and calibration.
Detectors
DTSA-II ties simulation and quantification together through the concept of detectors. In DTSA-II usage, a detector represents the logical description of a physical x-ray detector. Detectors are configured through the Preferences dialog (“File → Preferences” menu item, see Figure 4). The configuration allows the user to declare the properties of their instrument and x-ray detectors. Some of this information is used to calculate the detector response function. The detector response function is critical for accurate simulation. Some of the information is used to determine the position and width of measured characteristic x-ray lines. This information is critical for accurate quantification.
Figure 4: The preferences dialog shows the detector properties page. The software groups detectors by instrument. You can create a new instrument by selecting the “Instrument and Detectors” item in the navigation panel on the left and then add a new detector from the newly created instrument page.
Unfortunately some of this information is difficult to determine. Some information like the layer thicknesses within the detector is hard to come by. Sometimes the detector vendors can only provide approximate numbers. Do the best that you can. Obtain what numbers you can from your vendor and leave the rest at the default value. The most critical parameters can be calibrated later from spectra collected on your instrument (as will be discussed in a future article). See Table 1 for a list of detector configuration parameters with a basic description.
Table 1: Table 1. Information to describe a detector as implemented on the Preference dialog detector page (see Figure 4)
Figure 5: A schematic diagram showing how DTSA-II defines the various angles and distances necessary to describe the instrument/detector geometry. By convention, the origin is defined to be on the column axis at a working distance of 0 mm, and the positive z-axis is parallel to the direction of electron propagation.
You should define at least one detector configuration for each physical detector. You may want to define more. If you use a single detector with different energy calibrations (eV/channel or zero offset) or with different nominal resolutions (from changes in pulse process time), then you should declare one detector for each combination of parameters. For example, if you typically use either a “high” or “medium” throughput pulse processor setting and either 5 eV/channel or 10 eV/channel, you may want to have as many as four different detectors defined for this one physical detector.
When you first create a detector configuration, you will be asked to provide a nominal zero offset (eV), an energy scale (eV/channel), and a resolution (eV at manganese Kα). Later you won't be able to edit this information directly (the user interface elements are disabled). Instead you use the “Calibration Alien” to recalibrate the detector. The “Calibration Alien” can extract information like the energy calibration and the detector resolution directly from spectra.
The properties of a detector can change over time. To accommodate this, calibrations are stored to a database with a time stamp. When spectra are loaded, the acquisition time stamp of the spectrum is matched to the immediate prior calibration data.
The intimate tie between simulation and quantification through the detector model is an important characteristic of DTSA-II. The tie makes it easy to quantify simulated spectra and to simulate quantified spectra. This facilitates many different kinds of modeling and experiment optimization and is a major advantage of DTSA-II.
Spectrum Files
There are many different flavors of energy dispersive x-ray spectrum file formats, and DTSA-II reads many of them. The native format, which is both read and written, is the EMSA format [5], an International Standards Organization format for spectral data exchange. This format is supported by most vendors. It can also read the original DTSA file format, EDAX .spc files, Emispec files, IXRF Systems files, Radiant .spd files, Bruker .spx, and ASPEX .tif spectrum files. The “File → Open” menu item brings up a standard “file open” dialog with a spectrum preview window. When in doubt whether DTSA-II can read a file, the best course of action is to try. If you select the file in the spectrum “file open” dialog and it displays in the preview window, then DTSA-II understands the format. You may multi-select spectra to load more than one spectrum at a time.
Some spectrum files contain more information than others. The most critical information is the scaling of the energy axis. Without this, DTSA-II does not know how to translate channel data into a calibrated spectrum. Usually this information is recorded correctly in the spectrum file. Other important pieces of information may also be stored in the spectrum file, including the electron beam energy, the probe current, the acquisition live time, detector properties, and contextual data. In my experience, having read thousands of spectra from all over the world, it is rare that all this information is available or entirely correct when available. Some of this information is critical for high-quality analyses.
The following strategy has been adopted for DTSA-II when dealing with partial and incorrect information. In the “Spectrum” tab, which displays on the bottom half of the main application window, there is a drop list box that declares a “Default Detector” (see Figure 2). When spectra are loaded from disk, the basic properties read from the spectrum file are compared with the properties of the default detector. If they match, then the immutable properties of the “Default Detector” are applied to the spectrum. This may overwrite information provided in the spectrum file. This is usually a good thing because typically the default detector is more complete and accurate. If you don't want this behavior, select the “--None--” option from the top “Default Detector” list box.
The software does do some consistency checks. If the energy scale of the “Default Detector” doesn't match the energy scale read from the spectrum file (to a certain tolerance), then the program will ask whether you really want to apply the detector properties.
The “optimal detector calibration” is also automatically applied to the spectrum along with the “Default Detector” description. The optimal calibration is determined using the following scheme. Calibrations are associated with time stamps usually based on the time at which the calibration spectrum was collected. Spectra read from disk are associated with the most recent calibration collected before the spectrum file was created. This is usually reasonable because it encourages calibrating a detector before engaging in a measurement campaign.
You can change most of the spectrum properties in memory using the “Tools → Edit spectrum properties” menu item. You can declare that a spectrum represents a standard for a known material by using the “Tools → Assign material” menu item. These actions only change the data in memory. You have to save the modified spectrum to disk (“File → Save As” menu item) to make a permanent record.
Conclusion
This first article has provided a little flavor for DTSA-II. The most important terms have been defined, and the overall scheme for operation has been outlined. In forthcoming articles, I will try to fill in many details that were glossed over for the sake of brevity. The next article will discuss displaying and manipulating spectra and using the material database.
