Re: [Ifeffit] more bugs in atoms?
Hi George, thanks for responding. I sure imported the same structural information into atoms and the crystal structure program. Lisa
Hi Lisa,
I'm not very familiar with PbSO4, so I'm not sure if I can help, but your email immediately brought some questions to mind.
First, did you import the same information into atoms and the crystal structure program? The way you worded your message made me think that the crystal structure program already "knew" the structure of PbSO4, in which case perhaps it is using a structure that is slightly different from the one you import into atoms.
Second, what is the source of the structure data you are feeding into atoms? In my experience, errors and inconsistencies in the reporting of structure data in the literature can lead to unusual results in atoms.
Best, George
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 On Fri, May 13, 2011 at 5:00 PM, Gudrun Lisa Bovenkamp < bovenkamp@physik.uni-bonn.de> wrote:
Hi George,
thanks for responding. I sure imported the same structural information into atoms and the crystal structure program.
Lisa
Hi Lisa,
I'm not very familiar with PbSO4, so I'm not sure if I can help, but your email immediately brought some questions to mind.
First, did you import the same information into atoms and the crystal structure program? The way you worded your message made me think that the crystal structure program already "knew" the structure of PbSO4, in which case perhaps it is using a structure that is slightly different from the one you import into atoms.
Second, what is the source of the structure data you are feeding into atoms? In my experience, errors and inconsistencies in the reporting of structure data in the literature can lead to unusual results in atoms.
Best, George
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
George,
One way to assure that the paths aren't assumed to be degenerate would
be to use a different potential index for the different Fe sites. This
could be useful if the Fe sites are actually different. If they are the
same, you can treat them as separate paths when you fit by copying the
path and setting the degeneracy however you like along with whatever
fitting variables the paths require.
Jeremy
________________________________
From: ifeffit-bounces@millenia.cars.aps.anl.gov
[mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of George
Sterbinsky
Sent: Thursday, May 26, 2011 10:41 AM
To: XAFS Analysis using Ifeffit
Subject: Re: [Ifeffit] more bugs in atoms?
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
On Fri, May 13, 2011 at 5:00 PM, Gudrun Lisa Bovenkamp
participants (3)
-
George Sterbinsky
-
Gudrun Lisa Bovenkamp
-
Kropf, Arthur Jeremy