Apex Feedback

From Northwestern University Center for Atom-Probe Tomography
Jump to navigation Jump to search



There is some confusion about the current implementation for generating the concentration grid in Apex. Your Ultramicroscopy paper seems to describe a two-step process:

1)Create a grid (length="cellLength") & transfer atoms with cellLength
  wide transfer functions
2)Delocalize grid concentrations over length="DLoc"

Some people seem to recall you describing a one-step process:

1)Create a grid of length=cellLength & transfer atoms with a DLoc wide
  transfer function.

Can you please refresh our memory as to which is typically done? If it is the two-step process, is the second pass weighted by the number of atoms?

Apex uses the two step process.
The cellLength in step one determines the minimum possible delocalization distance.
There is no weighting by number of atoms in step two -- each atom is delocalized by the same distance all over the sample. However, the number of atoms information is retained, so that when an isosurface is drawn, it can be drawn with respect to a certain confidence.
Just to clarify:
Are you delocalizing the number of atoms or the relative concentrations?
Yes, the number of atoms.
The reason it is a two step process is for performance reasons. If performance was not a concern, we could delocalize each atom individually. However, calculation of the gaussian coefficients is a non-trivial calculation, and for millions of atoms, it wouldn't fly.
In the two step process, the first delocalization targets 27 grid points, using the cubic approximation that John Blatz came up with. Then in the second step, we can spend the time to calculate the real gaussian coefficients because the spacing between gridpoints is a constant and so we only have to the coefficients calculation once and use those values for all the gridpoints.
If the former, there is no need to weight by the total number of atoms in a voxel (as it is implicit). If you are delocalizing concentrations, they should be weighted with the total number of atoms in each voxel.
The only potentially counterintuitive bit is that the number of atoms in each voxel increases as the delocalization goes up (because the number of atoms contributing to the concentration calculations at that point goes up). In the limit of large delocalization, every gridpoint will approach having N atoms, where N is the number of atoms in the dataset. So if you want data where the number of atoms should be conserved, there's a little math required. Apex mainly uses the grid values for concentrations, so that's not a problem.
I hope that makes sense.
I think that I understand what you're saying, but I don't know the origin of this. If the delocalization Gaussian had an area of 1*N (N=number of atoms at a grid point), regardless of width, there should be a conservation of atoms (with the possible exception of all of the "outer" voxels, which could potentially "spill concentration" outside of the grid). Apparently the Gaussians in Apex have an area greater than 1*N? What area do they have?
Yes, that's why its tricky.
Perhaps it is easier to explain it from the point of view of the gridpoint -- each gridpoint is sampling the local concentration, and it does that by accumulating contributions from nearby atoms. The data for each gridpoint should depend on the nearby atoms, and the delocalization distance, but it shouldn't depend on the presence of other gridpoints.
In other words, let's compare two grids, one with exactly half the grid spacing as the other (and thereby, approx. 8x the number of gridpoints) and the same delocalization distance. One eighth of the gridpoints in the finer grid will have the same x,y,z coordinate as a point in the coarser grid. Because the delocalization distance is the same, those gidpoints should be identical in both grids (ideally anyway *). Thus, when we calculate statistical values such as confidence and deviation, we have to have a #atoms contributing to the gridpoint. It is this number of atoms which does not get conserved. Otherwise our statistics would get worse as the grid gets finer, which is exactly what we want to prevent.
  • Ideally, because of the cubic approximation in the initial splat, the results won't be exactly identical, but will be really close.
Now, explaining this to you makes me think that I have been underestimating the statistics by a factor of 1.25 -- the first splat effectively makes the area of the gaussian 1.25 and not 1, which is what I believe is assumed in the code. I suppose the good news is that the error is not the other way (i.e. 1 sigma in Apex errs on the conservative side rather than the fast and loose side), but I need to think about this again to make sure that's actually the case.

Import regular grid

Also: we have gridded sets, where we know the number of atoms at each regularly spaced point. It would be nice to be able to import this and do one or both of the following (without having to regrid the data):

1)Generate an isosurface
2)Delocalize over some Dloc length &  then generate an isosurface

Any suggestions?

do you mean you have data external to atom, and you'd like to create a concentration space with that external data, rather than from the in-sample atoms? If so, I understand the request
Yes, that is correct. Our current data is a CSV file where each line looks like:
with x,y,z being the grid points (regularly spaced) and n_1 through n_i being the number of atoms of a particular type (from i types of atoms) at that particular grid point.


And finally: we are also interested in being able to dump one or both:

1)number of atoms of every type at every grid point
2)the vertices of an iso-concentration surface.
These are already available by script:
Surfaces have triangle elements, and the triangles each have a vertex coordinates property.
concentration spaces have gridpoints, which in turn have a concentration property.
I can understand if you'd like a faster data dump ( scripts can be slow ). Specify the format, and I'll try to do something if it is easy enough -- these would make great example plugins, actually.
We came up with this idea recently & should probably get it via script first.
That being said, I agree that it would probably be useful to see one of these implemented as a plugin. Chantal wants to extract the isosurface information, so perhaps that should be the first one to see. Perhaps a single CSV for a single surface with each line bearing three points from a single triangle:
(Of course exporting the grid would also help us test importing a grid, if that worked. But I assume seeing how one is implemented will make the other trivial to implement.)