Re: [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 georgesterbin...@u.northwestern.edu
To: XAFS Analysis using Ifeffit ifeffit@millenia.cars.aps.anl.gov
Subject: Re: [Ifeffit] more bugs in atoms?
Message-ID: BANLkTi=OH=ncjjmwhke5vlmnteao8k3...@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.51120b =  5.51120c =  7.79410
alpha = 90.0beta = 90.740gamma = 90.0
core =Co1edge =Krmax =  6.0
!shift   0.25000   0.25000   0.25000
atoms
! elem   x  y  z tag   occ.
 Fe0.00.00.0  Fe1   1.0

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



___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] more bugs in atoms?

[George Sterbinsky]

Hi Lisa,

The typo in the core atom does not affect the result if run in Artemis. I
think I now have a better grasp of why atoms cannot run my structure
correctly. The standard i2/c setting has a unique axis a, but the structure
in the input file below has a unique axis b. This appears to through atoms
off. If I convert to an I2/a setting, then I get the correct results without
a shift vector.

George



On Fri, May 27, 2011 at 1:40 PM, Gudrun Lisa Bovenkamp 
bovenk...@physik.uni-bonn.de wrote:

 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 georgesterbin...@u.northwestern.edu
 To: XAFS Analysis using Ifeffit ifeffit@millenia.cars.aps.anl.gov

 Subject: Re: [Ifeffit] more bugs in atoms?
 Message-ID: BANLkTi=OH=ncjjmwhke5vlmnteao8k3...@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.51120b =  5.51120c =  7.79410
 alpha = 90.0beta = 90.740gamma = 90.0
 core =Co1edge =Krmax =  6.0
 !shift   0.25000   0.25000   0.25000
 atoms
 ! elem   x  y  z tag   occ.
  Fe0.00.00.0  Fe1   1.0

 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


  ___
 Ifeffit mailing list
 Ifeffit@millenia.cars.aps.anl.gov
 http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit