The Reconstruction Summit Wrap

February 25, 2007

Well, I’m really late writing this, but a big thank you to Tom Kelly and everyone at Imago for putting together the reconstruction summit. Mineral Point, WI is extremely cold in February, but it was an ideal place to get a small group of scientists together for brainstorming. The Jones Mansion is quite a nice place, too. You can see the room I stayed in on their homepage — in the picture on the left, right through the bright doorway.

The scientific content of the meeting is under “Gordon Conference” style embargo, meaning that none of the
participants are free to discuss the content, but I can say what I took away from it as future work for myself. One of the basic issues with the current data workflow for the LEAP right now is that the raw data files from the LEAP are in a less-than-fully-open format.

That’s not good for researchers, because its hard to tinker with data that’s trapped in a proprietary format. That’s not good for Imago, either, because the last thing Imago wants to spend time and effort on is tinkering with reconstruction algorithms. So there’s a need for some common code to interpret and make accessible the large amounts of data in a raw data from the LEAP. I’m one of the people who volunteered to help maintain a repository of code. We’ll need the cooperation of the folks at Imago, but we’ll see how it goes.

And for the record, I tried cheese curds, but they didn’t squeak.

Test Suite Timing Comparisons

January 18, 2007

Part of the release procedure for Apex is that I run the test suite on the compiled app. ‘The test suite’ is currently nine AppleScripts which run Apex through a lot of its paces — importing and exporting files, calculating a proxigram, saving an animation as a QuickTime movie, running the select particles in shell action from the isosurfaceOps plugin, and most recently I’ve added an rdf export.

I run the suite once on a PowerPC machine and once on an Intel-based machine. If the test succeeds, its a pretty good indication that the build is OK to go out the door. It doesn’t catch issues in the GUI, and it doesn’t run through all the functionality, but it gets a good deal. For example, the most recent problem I discovered was that one of the plugins was building for PowerPC only because of a glitch in the XCode config files.

Of course, one of the things that I monitor is how long each script takes, so I can verify that I haven’t screwed anything up too much in making changes for each release. And the other thing is that, having an automated test suite means its pretty easy to move the test to new machines. So I’ve done a little comparison of performance on a few different machines. From slowest to fastest:

G4 PowerBook , 1.25 GHz: 508 seconds
G4 PowerMac, Dual 1.25 GHz: 462 seconds
G5 PowerMac, Dual 2 GHz: 250 seconds
iMac, 1.83GHz Intel Core 2 Duo: 209 seconds
MacBook, 2 GHz Core Duo: 192 seconds
MacPro, Dual 2.66GHz Xeon: 133 seconds

These are all running 10.4.8. All in all, its about what you would expect, but I must say I’m very impressed by the MacBook.

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