[Ifeffit] atoms possible bugs

Bruce Ravel bravel at bnl.gov
Tue May 10 14:04:31 CDT 2011

On Tuesday, May 10, 2011 02:21:07 pm George Sterbinsky wrote:
> I have attached two atoms input files, generated using the Artemis atoms
> interface. The file A2n_atoms.inp is for a monoclinic structure in the A
> 2/n setting. On running atoms, one will find that there are six Ga atoms
> within a 4 A radius from the central Ga atom. If one reduces the the
> cluster size from 8 A in the .inp file to 6 A, one finds that now there
> are only two Ga atoms within 4 A of the central Ga atom. So it appears
> that atoms does not necessarily include all atoms within the cluster
> radius. The leads me to the question: how big should I make the cluster if
> I want to include all atoms within 6 A?

Hi George,

This is an obscure bug and one that is pretty deep in the details of
how atoms does its thing.  To explain what I suspect is going on, I
need to explain a bit about how Atoms works.

 Step 1: Atoms fills one entire unit cell with atoms

 Step 2: If more than one atoms of the absorber species lives in the
      fully decorated unit cell, the one closest to the center of the
      unit cell is chosen as the central atom.

 Step 3: A rhomboid is contructed by stacking up enough unit cells in
      all three directions to completely encompass a sphere of radius
      rmax centered at the chosen absorber.

 Step 4: All atoms within the rhomboid but outside the sphere are
      discarded.  All atoms within both the rhomboid and the sphere
      are sorted by distance.

I suspect that the bug is in the construction of the rhomboid.  I
suspect that the beta angle of your cell is not handled correctly when
deciding how many unit cells to stack up and that the sphere is not
fully encompassed.  As a result, atoms get left out of the resulting
feff.inp file.

Fortunately, you have discovered the work-around -- make Rmax bigger.
In fact, go ahead and make Rmax substantially bigger, say 8 or 9
Angstroms.  Then edit RMAX in the feff.inp file to be the radius to
which you actually want to compute scattering paths.

I'll put this bug on the todo list, but I do want to point out that
making the cluster larger than the distance to which you want to do
data analysis is good practice in general.  In fact, the next version
of Atoms will allow you to specify the cluster size and the feff RMAX

That said, this bug suggests that, for non-orthogonal clusters, you
probably cannot trust Atoms to get the population on the periphery of
the cluster correct.  If you are doing EXAFS analysis and you set the
cluster size to be 8 or more Angstroms, this is unlikely to ever be a
serious problem.



 Bruce Ravel  ------------------------------------ bravel at bnl.gov

 National Institute of Standards and Technology
 Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2
 Building 535A
 Upton NY, 11973

 My homepage:    http://xafs.org/BruceRavel
 EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/

More information about the Ifeffit mailing list