[Ifeffit] more bugs in atoms?

[Gudrun Lisa Bovenkamp]

Hi George,

I cannot understand how you got this atoms.inp file where the core is 
stated to be Co1 and there is only Fe. So, I cannot confirm the 
crystal structure from a database.
My problem is solved. I understood that the ATOMS program implemented 
in Arthemis and ATOMS 2.5 have some bugs that are corrected in ATOMS 
3.0 and WebATOMS. When I use those two programs I get a correct 
crystal structure xyz table in feff.inp.
the only reason that I can think of, why your shifting seem to work 
better is that the atoms.inp file was not representing the correct 
structure in the first place. This can happen when the situation you 
wnat to describe is not the situation that was measured by somebody 
else. Or there is a mistake in the paper.
Anyway. Thanks for sharing this idea.

Lisa



> Date: Thu, 26 May 2011 11:41:08 -0400
>From: George Sterbinsky <GeorgeSterbinsky at u.northwestern.edu>
> To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
> Subject: Re: [Ifeffit] more bugs in atoms?
> Message-ID: <BANLkTi=OH=NCJjmwhkE5vLmnTEao8k3avg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Lisa,
> 
> Let me just mention one situation I have encountered using atoms, 
>and how I
> resolved it. I am not sure if this is the result of a bug or not, 
>but
> perhaps you can try applying the approach I took to your own 
>situation and
> see if it can resolve your problem.
> 
> The issue I encountered was running atoms for a monoclinic I2/c 
>structure,
> space group 15.
> 
> Here is the atoms input file:
> 
> ! This atoms input file was generated by Artemis 0.8.014
> ! Atoms written by and copyright (c) Bruce Ravel, 1998-2001
> title = ...
> space = i 2/c 1 1
> a =      5.51120    b =      5.51120    c =      7.79410
> alpha =     90.0    beta =     90.740    gamma =     90.0
> core =    Co1    edge =    K    rmax =      6.0
> !shift   0.25000   0.25000   0.25000
> atoms
> ! elem   x          y          z     tag           occ.
>  Fe    0.00000    0.00000    0.00000  Fe1           1.00000
> 
> If one calculates the Fe-Fe distance between the atom at (0,0,0) and 
>the
> atom at (0, 0, 0.5), from application of the (x, -y, -z+0.5) lattice
> translation, one finds a Fe-Fe distance of 3.9705. However, if one 
>runs the
> above atoms input file, this Fe-Fe distance is not found. Instead, a 
>shift
> vector of (0.25, 0.25, 0.25) is needed to get the correct Fe-Fe 
>distance.
> Note, the i2/c space group is listed with only one origin in the
> international tables. I determined the necessary shift vector from 
>trail and
> error. It is still unclear to me why it was necessary to include a 
>shift
> vector. So the best suggestion I have is that you can try including
> different shift vectors in your own atoms.inp file and see if you 
>can get
> agreement with the crystallography program that way. Since, as I 
>said, it
> isn't clear to me why this fixed my problem, its hard to say if this 
>is the
> same issue you are having, but it may be worth a try.
> 
> It may also be worth while to calculate some atomic distances from 
>the
> lattice positions given in the international tables, and see if 
>atoms or the
> crystallography program is giving you the same thing.
> 
>Finally, let me add on another question for the list here since it is
> somewhat related. When one runs the above atoms.inp file with the 
>(0.25,
> 0.25, 0.25) shift vector one finds four Fe1_1 atoms at 3.9701 and 
>two Fe_2
> atoms at 3.9705. When one then runs Feff, it combines these into a 
>single
>Fe1_1 scattering path with N=6. Is there a command can be placed in 
>the Feff
> input file to tell Feff not to combine identical paths like this?
> 
> Best,
> George
> 
>