The Reconstruction Summit

January 17, 2007

Imago is hosting a two-day mini conference on reconstruction issues in 3D Atom Probe Feb 5 and 6 in Mineral Point, Wisconsin. Maybe more like a retreat, as Mineral Point is a rather out-of-the-way bit of Wisconsin — a bit of history, and bit of artist colony, a bit of bed and breakfast. In any case, it should be a solid two days with Atom Probe scientists from around the world. I just got my tickets a few days ago.

Improvements in Apex a46

January 16, 2007

The selection property of a document is now working as expected. This means one can set the selection with a command like this:

set the selection of document 1 to {34, 46, 47, 49, 56}

Which will select 5 ions, or clear the selection with

set the selection of document 1 to {}

The ‘select particles in sphere’ verb is implemented as part of the RDF plugin, and the export rdf command is working from a script as well:

tell document 1
set the selection 1 to {}
select particles in sphere centered at {0,0,100} with radius 10
export rdf saving in (“Macintosh HD:my folder” as alias) filename “rdf” relative to atomtype 2 total bins 500 radial cutoff 20
end tell

When importing a POS file, the selection is now correctly set to nil.

‘get coordinates of ion n’ now works as a shorthand for ‘get {x coordinate, y coordinate, z coordinate} of ion n’

Improvements in Apex a45

January 11, 2007

Apex a45 fixes the Atomtypes dialog. There were some drawing issues with this dialog that got a lot in one of the last few releases as I was updating to use more HIView based code. Its fixed now.

Improvements in Apex a44

January 8, 2007

Mostly, this update provides a select particles in sphere action as part of the new RDF plugin. Part of the reason to do this is to get an easy way to define a selection for an RDF to act on. It makes sense to do it in the RDF plugn so that test scripts for RDF can be guaranteed to have this feature available.

Now, select particles in sphere should really be part of the main application, but to do it right, one should be able to define a sphere object in the same way that you can define a cylinder or plane object. Actually, ellipsoid would be more general. That will be a little extra work, so for now, its just a simple function in the RDF plugin.

An RDF example using the Apex RDF plugin

December 12, 2006

Apex a43 includes a new RDF generation plugin. Here’s an example of some data taken with the plugin. Thanks to Dieter Isheim of Northwestern University for a sample dataset. In this case, it is the Fe alloy with Ni, Cu and Al, and a number of other components. In the picture below, Cu atoms are in red, and visually they appear in clusters.

First, I use ‘Select Points’ mode to make a simple selection in the dataset. Thats the rectangular area shown where the atoms are drawn slightly darker. This selected range includes about 118,000 atoms, 2093 of which are Cu atoms. These 2093 atoms will be used as the reference points in the RDF calculation.

From Clipboard.gif

I choose the ‘RDF Export’ menu item and select the parameters I want — Cu atoms for reference, 1600 bins and cutoff radius of 40 Ångstroms. I specify the name for the output file, in this case ‘Cu44 3.rdf’. The calculation takes 40 seconds. In that time, Apex has gone through each of the 2093 Cu atoms, found all of the other atoms in the dataset in a 40 Ångstrom radius, and measured the distance to each reference atom and binned all the results, writing out a tab-delimited file. I go to my graphing application proFit , and choose ‘Import’. Here I can specify that the file contains its own column headers,and this is the window that gets created:


In short order, I’ve got a graph that looks like this:


A few things to note. The red line is the most interesting. What it means is that the density of Cu is a lot higher near your average Cu atom than further away: That’s the same thing as seeing the Cu atoms in clusters in the atom map, but in the RDF, you can see how big the clusters are. The plot drops down significantly between 5 and 10 Ångstroms, which is indicative of clusters of about 20 Ångstroms in size. This kind of data is fun to interpret, because it is an average over all the reference atoms, some of which are in the center of a cluster, some of which are near the edge of a cluster, and the clusters aren’t necessarily spherical or uniform in size.

Second thing to note is that the Ni and Al also have slightly higher concentrations near Cu than farther away, but that the Aluminum concentration drops off faster than the Ni — out at a radius of 20 Å, the Ni concentration is double that of the Al. So there is a much stronger correlation of the Al with the Cu than of Ni with Cu.

the Fe concentration stays pretty flat despite a higher density of the other components near Cu atoms. Does this mean that there is actually a higher atomic density in the sample near the Cu clusters? Well, no. There are any number of Atom Probe conditions which might cause this sort of data anomaly: one possibility is that the radius of the tip may change as a function of chemical composition of the tip — and thus the magnification changes, too, producing changes in the apparent density. This effect is quite common. The efficiency of detection may also change as a function of composition — the Atom Probe may only collect 50% of the atoms in any given sample — other are lost due to bad ion optics, or evaporation outside of the pulse window, or multiple atom evaporation, or other electrical noise. Another effect is that some of the reference atoms may be close to edges in the dataset itself, which means that those reference atoms are not surrounded by a 40 Å radius of atoms, which would result in a decrease of the total density with increasing radius.

A common ploy to correct all these effects is to make a plot of concentration, rather than density (Dieter says he prefers that, actually). It is easy to do that in this case, as the total number of atoms is already supplied in the dataset in column 2.

Some RDF datasets also show short range order: that is, down in the 2 -3 Ångstrom range, it is possible to see the effects of first-nearest neighbor positions vs, second or third nearest neighbor positions. This dataset doesn’t show any such interesting pattern.

Lastly, one feature of the RDF that we calculate is the gradually changing binsize. As noted here previously, data analysis in the Atom Probe is often a tradeoff of positional error vs. statistical sampling error. Because the number of atoms at a given radius increases with r squared, we expect to have less error in the measurement at higher radii. In our calculation, we show both lower sampling error and lower statistical sampling error as the radius increases, by decreasing the binsize with increasing radius. This is reflected in the data: At lower radii, the scatter in the data is higher, and there is slightly more distance between the datapoints.

Radial Distribution Function Plugin

December 10, 2006

With Apex a43, there is now a plugin module that calculates a radial distribution function, or RDF. The RDF is one way of analyzing the local environment of atoms in the dataset. The calculation looks at all the neighboring particles of a particular atom (the reference atom), and collects the distance between that reference atom and each neighbor, and the atomtype of that neighbor. This information is compressed onto a single graph, the y axis representing the density of neighboring atoms of each type, and the x axis representing the distance of separation.

Usually, the data collected relative to a single atom is neither representative of the whole sample, nor is the statistical error low enough to have confidence in the results. Typically, the RDFs of many reference atoms are combined into a single plot. The RDF calculation in Apex operates on the current selection, and only on the atoms of a given atomtype.

When RDF calculation is enabled, there is a menu item called ‘RDF Export’ under the Plugins menu. Selecting this menu item offers the following choices for the calculation parameters:


Only atoms of the specified atomtype will be used for the RDF, and only those which are in the current selection. The distribution will be generated as a histogram with the given number of bins, and the last bin will represent radial separation of the specified cutoff radius.

The RDF will be output as a text file with tab-delimited columns and return delimited radius values. This file can be imported into a graphing application such as proFit with little effort.

If you are using proFit, select ‘Open…’ from the profit ‘File’ menu. Select the display ‘All Files’ option to be able to select the generated .rdf file. When importing, you will be presented with this dialog:


Choose the ‘with title’ option from the format popup menu. This will direct profit to use the first line of the text file as the column headers in the generated dataset.

One of the quirks of RDF generation is that as the radius increases, the number of atoms N in a shell of thickness Δr increases with r2. As is common with the interpretation of atom probe data, there is always a trade off between statistical error and positional error. If the binsize were to remain constant in the RDF histogram, this would mean that the statistical error would decrease as a function of 1/r , because the statistical error is proportional to sqrt(N). But because of the constant binsize, the positional error would remain constant through the data. This is non-ideal because at small radii, the statistical sampling error is much higher than the positional error, and at high radii, the positional error is higher than the statistical error. Instead, Apex generates an RDF with a continuously decreasing binsize, so that both the statistical error and positional error decrease with increasing radii proportional to sqrt(1/r). That is, as the radius increases, the binsize gets smaller by a factor of 1/sqrt(r) and the number of atoms per bin gets larger by a factor of r. The choice of number of bins and radial cutoff combine to determine the tradeoff between positional error and statistical sampling error.

As of Apex version a43, the value of the calculated RDF is in units of atoms per cubic Angstrom times the number of reference atoms. This will be changed in the future to be simply atoms per cubic Angstrom, so that the data is invariant to the number of atoms selected. In Apex a44, the units will be Atoms per cubic nanometer.

In addition, the radius value is given as the arithmetic average of the inner radius and the outer radius of the given shell. This is less than ideal for small radii, because for small radii, the number of atoms near the outer radius is higher. In other words, for the shell from radius = 0 to radius = 1, the current RDF labels the bin as r = 0.5, although the mean radius should be close to 0.8. In Apex a44, will have a radius value appropriately weighted toward the higher radius.

The Intel Mac Pro

August 26, 2006

Now that’s a screaming machine. Here’s Apex on Intel:


The colors are a little off on intel — must be a byte switching issue — perhaps ‘ARGB’ became ‘BGRA’ ???

In any case, Calculations are approximately twice as fast compared with my dual G5 machine, and most things just work. I’ll be releasing soon.

– Olof

Improvements in Apex a42

August 26, 2006

The biggest feature here is that I fixed the sliders in the isosurface properties pane — the sliders weren’t working correctly. Now, not only are they working correctly, they are drawing really fast on live feedback. It’s really a great illustration of how the confidence sigma value improves the data along the edges.

More stuff here includes some under the hood work for intel doing reading of kozo format files. This shouldn’t affect most folks.

– Olof

Filming a Movie

May 29, 2006

A simple script to show how animations are done:

tell application “Apex”
starting the movie
set destinationFile to “Macintosh HD:coercion movie”
start filming of window 1 of document 1 saving in destinationFile
saving movie frames
repeat 90 times
rotate window 1 of document 1 axially 0.1
rotate window 1 of document 1 vertically 1
save movie frame of window 1 of document 1
end repeat
stopping the movie
stop filming of window 1 of document 1
end tell

Basically, there are three phases of the script: starting the filming, saving frames, and stopping the filming.

In this script, the name of the movie is hard coded. That’s a problem if you’d like to run the script a number of times. If you’d like to generate a different name for the movie each time, try doing this:

set secs to (( current date ) – (date “Sunday, January 1, 2006 12:00:00 AM” ))as text
set destinationFile to “Macintosh HD:movie ” & secs

secs will be the number of seconds since the first of the year, so as long as you wait one second between script runs, you’ll have a different name for the movie file. Or perhaps you’d like to name the file with a traditional Mac OS put file dialog. In which case, do this:

set destinationFile to choose file name

You’ll have interesting results if you change the size of the window while the script is running. QuickTime movies have a fixed size, so the size that you start with is the size you’ll get no matter what.

Imago Buys Oxford Nanoscience

April 13, 2006

The title says it all. Here’s the press release from Polaron:

Here’s my take on the situation:

Essentially, Polaron is getting out of the Atom Probe business, no doubt because the Imago had better technology and better approach to sales and developing a business. When Oxford’s main competitor was Cameca/Rouen, Oxford had the upside of being the preferable instrument for sales to industry, whereas the Cameca/Rouen instrument was better suited to the research lab.

With the ascendence of Imago’s LEAP, the high end of Oxford’s business was essentially cut off, and Polaron was left to fight for academic scraps with Cameca. Now, Cameca might be able to justify that because of their other academic oriented research instruments, and with the level of the collaboration they have with Rouen. Polaron, however, found it just wasn’t worth it for the small market that exists for Atom Probes.

Imago, meanwhile, gets a significantly cleaner playing field and some technology thrown in as well, so as long as the price doesn’t sink them, it seem like a good deal for them. Polaron, meanwhile, exits gracefully from the market with a little cash and a continuing investment, and more time to focus on their core business. Not a bad deal there, either.