Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Robert Gordon]

Hi Bruce,

I looked at Site.pm and Cell.pm as well (and I don't program in perl, so 
please forgive

any naivete).

In Site.pm, lines 188 - 191, it says:
#-- rotate from F or C settings to P or I
  if ($is_tetr) {
($x, $y) = ($x-$y, $x+$y);
  };

and this looks like a 45 degree rotation to me, and I can understand why if
someone specified a cell that was "c-centred tetragonal" which is really P
or face-centred tetragonal being I, but is it being applied to all 
tetragonal systems?


In Cell.pm, lines 516 - 521, it says:
  ## rotate a tetragonal group to the standard setting
  if (($crystal_class eq "tetragonal" ) and ($setting ne 'positions')) {
my ($a, $b) = $self->get(qw(a b));
$self->a($a/sqrt(2));
$self->b($b/sqrt(2));
  };

but I see a re-scaling, not a rotation.

Possibly related: When I look at Site.pm on my linux box, from line 134 
on, it is almost all
purple. z and utag are highlighted in red, as is $self on line 138. The 
file looks normal
on github, but if I copy it, these colour changes manifest. I normally 
associate

blue with comments, purple with text strings, green for $self...

thanks,
-R.

On 12/21/2016 12:58 PM, Bruce Ravel wrote:

On 12/21/2016 02:50 PM, Robert Gordon wrote:

So, for all but tetragonal, the orientation of the cluster can be
identified with the
orientation of the crystal axes. Does it not seem more logical to
preserve the
apparent orientation with respect to the crystal axes so that, when
using POLARIZATION
(issues in FEFF6 aside), confusion is less-likely?


Hmm ... I think I understand your point.

I think you may be ascribing too much agency and intelligence to the 
the Atoms algorithm.  The way Atoms works these days is to use this 
tabulation of chapter 7 of volume A of the International Tables:


https://github.com/bruceravel/demeter/blob/master/lib/Xray/Crystal/share/space_groups.db.PL 



It selects the symmetry operations appropriate to the specified space 
group and applies them to the list of unique coordinates. In the case 
of a space group with multiple settings, it uses some heuristics to 
try to guess the correct setting.  (That's what things like "b_unique" 
and so on are all about.  Those heuristics often fail.)  It expands 
out a unit cell and weeds through the unit cell to identify duplicates 
(i.e. high symmetry positions that repeatedly generate the same 
location when the symmetry operations are applied).  It then stacks up 
enough unit cells to contain the cluster, then translates fractional 
coordinates to Cartesian coordinates.


At no point in that operation does the program make any decisions on 
the basis of the definitions of the Cartesian axes.


None of this is a value judgment on what you have said or on Raj's 
original question -- I'm simply explaining how the program works. 
There just isn't an obvious mechanism in the code to let the user 
orient the cluster in a certain way.  That's an interesting idea, but 
not something available at this time.


To use Feff's polarization, you have to choose a polarization vector 
appropriate to the cluster as written.  Or, I suppose, write your own 
tool to rotate the cluster to a more convenient orientation.


B





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

Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Bruce Ravel]

On 12/21/2016 02:50 PM, Robert Gordon wrote:

So, for all but tetragonal, the orientation of the cluster can be
identified with the
orientation of the crystal axes. Does it not seem more logical to
preserve the
apparent orientation with respect to the crystal axes so that, when
using POLARIZATION
(issues in FEFF6 aside), confusion is less-likely?


Hmm ... I think I understand your point.

I think you may be ascribing too much agency and intelligence to the the 
Atoms algorithm.  The way Atoms works these days is to use this 
tabulation of chapter 7 of volume A of the International Tables:


https://github.com/bruceravel/demeter/blob/master/lib/Xray/Crystal/share/space_groups.db.PL

It selects the symmetry operations appropriate to the specified space 
group and applies them to the list of unique coordinates.  In the case 
of a space group with multiple settings, it uses some heuristics to try 
to guess the correct setting.  (That's what things like "b_unique" and 
so on are all about.  Those heuristics often fail.)  It expands out a 
unit cell and weeds through the unit cell to identify duplicates (i.e. 
high symmetry positions that repeatedly generate the same location when 
the symmetry operations are applied).  It then stacks up enough unit 
cells to contain the cluster, then translates fractional coordinates to 
Cartesian coordinates.


At no point in that operation does the program make any decisions on the 
basis of the definitions of the Cartesian axes.


None of this is a value judgment on what you have said or on Raj's 
original question -- I'm simply explaining how the program works.  There 
just isn't an obvious mechanism in the code to let the user orient the 
cluster in a certain way.  That's an interesting idea, but not something 
available at this time.


To use Feff's polarization, you have to choose a polarization vector 
appropriate to the cluster as written.  Or, I suppose, write your own 
tool to rotate the cluster to a more convenient orientation.


B



--
 Bruce Ravel   bra...@bnl.gov

 National Institute of Standards and Technology
 Synchrotron Science Group at NSLS-II
 Building 743, Room 114
 Upton NY, 11973

 Homepage:http://bruceravel.github.io/home/
 Software:https://github.com/bruceravel
 Demeter: http://bruceravel.github.io/demeter/
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Robert Gordon]

Hi Bruce,

Sorry, I was just using the different space group just to get the 
cluster to be oriented
along the axes or at 45 degrees. With tetragonal symmetry, the cluster 
is oriented
at 45 degrees with respect to the axes. If I don't use tetragonal 
symmetry, then the

cluster is oriented as one might expect with respect to the axes.

Raj's original question was about producing these two different 
orientations of the cluster,

with one version of atoms produced the rotated and another the non-rotated.

You investigated Raj's observation by running FEFF6.

My point is more general, but still related to Raj's case in that, if 
the coordinates are rotated,
a different result is obtained if one does a polarization-dependent 
FEFF6 calculation than

if the coordinates are not rotated.

So, Raj's observation of the rotation of the cluster with respect to the 
axes exposes an
issue when running such a rotated cluster in FEFF6 with respect to 
POLARIZATION,

versus a non-rotated cluster.

NOTE: In FEFF6, one actually gets a different result (in the bct model I 
discussed) if one uses
(100) versus (010) with the POLARIZATION card. This does not seem to 
happen for FEFF7.
i.e. even for tetragonal symmetry, FEFF6 calculates some differences for 
orientations rotated by 90

degrees in-plane.

As a convention, having the cluster oriented so that POLARIZATION agrees 
with axes
does seem logical. For tetragonal symmetry, Demeter-Atoms seems to 
rotate the cluster.
(I haven't checked hexagonal/trigonal) such that this does not appear to 
be the case.


You could, instead of the bct example I used, work with just bcc Fe.
In cubic, Demeter-Atoms generates a cluster in the feff.inp

   0.00.00.0  0  fe0.0
1.433001.433001.43300  1  fe.1  2.48203
   -1.433001.433001.43300  1  fe.1  2.48203
1.43300   -1.433001.43300  1  fe.1  2.48203
   -1.43300   -1.433001.43300  1  fe.1  2.48203
1.433001.43300   -1.43300  1  fe.1  2.48203
   -1.433001.43300   -1.43300  1  fe.1  2.48203
1.43300   -1.43300   -1.43300  1  fe.1  2.48203
   -1.43300   -1.43300   -1.43300  1  fe.1  2.48203
2.866000.00.0  1  fe.2  2.86600
   -2.866000.00.0  1  fe.2  2.86600
0.02.866000.0  1  fe.2  2.86600
0.0   -2.866000.0  1  fe.2  2.86600
0.00.02.86600  1  fe.2  2.86600
0.00.0   -2.86600  1  fe.2  2.86600

and if one drops to tetragonal symmetry, same cell, same contents, just 
using lower symmetry

for s, one obtains

   0.00.00.0  0  fe0.0
2.026570.01.43300  1  fe.1  2.48203
   -2.026570.01.43300  1  fe.1  2.48203
0.02.026571.43300  1  fe.1  2.48203
0.0   -2.026571.43300  1  fe.1  2.48203
2.026570.0   -1.43300  1  fe.1  2.48203
   -2.026570.0   -1.43300  1  fe.1  2.48203
0.02.02657   -1.43300  1  fe.1  2.48203
0.0   -2.02657   -1.43300  1  fe.1  2.48203
2.026572.026570.0  1  fe.2  2.86600
   -2.026572.026570.0  1  fe.2  2.86600
2.02657   -2.026570.0  1  fe.2  2.86600
   -2.02657   -2.026570.0  1  fe.2  2.86600
0.00.02.86600  1  fe.2  2.86600
0.00.0   -2.86600  1  fe.2  2.86600

which appears to be rotated 45 degrees with respect to the bcc variant, 
and if I drop

down to orthorhombic (Immm), again, same cell

0.00.00.0  0  fe0.0
1.433001.433001.43300  1  fe.1  2.48203
   -1.433001.433001.43300  1  fe.1  2.48203
1.43300   -1.433001.43300  1  fe.1  2.48203
   -1.43300   -1.433001.43300  1  fe.1  2.48203
1.433001.43300   -1.43300  1  fe.1  2.48203
   -1.433001.43300   -1.43300  1  fe.1  2.48203
1.43300   -1.43300   -1.43300  1  fe.1  2.48203
   -1.43300   -1.43300   -1.43300  1  fe.1  2.48203
2.866000.00.0  1  fe.2  2.86600
   -2.866000.00.0  1  fe.2  2.86600
0.02.866000.0  1  fe.2  2.86600
0.0   -2.866000.0  1  fe.2  2.86600
0.00.02.86600  1  fe.2  2.86600
0.00.0   -2.86600  1  fe.2  2.86600


back to being apparently aligned as with the bcc...and so forth down to P1.
So, for all but tetragonal, the orientation of the cluster can be 
identified with the
orientation of the crystal axes. Does it not seem more logical to 
preserve the
apparent orientation with respect to the crystal axes so that, when 
using POLARIZATION

(issues in FEFF6 

Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Matt Newville]

Robert,


On Wed, Dec 21, 2016 at 12:13 PM, Robert Gordon 
wrote:

>
> Hi Bruce,
>
> The atoms.inp file attached is for bct Fe. In symmetry I4/mmm, the
> resulting feff input has the coordinates
> rotated, while in Immm the resulting coordinates are not rotated relative
> to the crystal axes (i.e. in Immm
> the 2nd near neighbour is obvious as a lattice constant away in each
> direction).
>
> So, with no polarization, the results for scattering paths are the same
> (using CRITERIA default), as expected
> Path #
> Degen
> Reff
> Scattering Path
> Type
> Rank I4/mmm
> Rank Immm
> 1
> 8
> 2.48
> fe1
> ss
> 100
> 100
> 2
> 4
> 2.835
> fe2
> ss
> 37.56
> 37.56
> 3
> 2
> 2.92
> fe3
> ss
> 17.59
> 17.59
> 4
> 16
> 3.897
> fe1-fe1
> ms
> 3.42
> 3.42
> 5
> 32
> 3.897
> fe1-fe2
> ms
> 12.83
> 12.83
> 7
> 16
> 3.94
> fe1-fe3
> ms
> 6.37
> 6.37
>
> Now consider with  POLARIZATION 1 0 0 (and 1 1 0 for I4/mmm)
>
> #
> Degen
> Reff
> Scatt. Path
> Type
> I4 1 0 0
> I4 1 1 0
> Im 1 0 0
>
> 4
> 2.48
> fe1
> ss
> 100
>
>
>
> 4
> 2.48
> fe1
> ss
> 7.89
>
>
>
> 8
> 2.48
> fe1
> ss
>
> 100
> 100
>
> 4
> 2.835
> fe2
> ss
> 55.45
>
>
>
> 2
> 2.835
> fe2
> ss
>
> 62.05
> 62.05
>
> 16
> 3.897
> fe1-fe1
> ms
> 4.41
> 9.90
> 15.43
>
> 16
> 3.897
> fe1- fe2
> ms
> 19.03
> 21.58
> 21.59
>
>
> For that first multiple scattering path, the scattering angles are 36.1/90
> for I4(1 0 0), 55.1/55.1
> for I4(110) and for Im(100) they are 55.1/124.9. The ranking of this path
> is not the same,
> and the plots for this path differ as well - in shape as well as
> amplitude.
>
> Conceptually, the Immm model calculation has the atoms aligned with the
> crystal lattice
> and the I4/mmm has the atoms rotated. FEFF sees a difference, and I would
> take
> the Immm result as the correct one based on the positions of the atoms in
> the cluster
> relative to the axes.
>
> -R.
>


Doesn't that assume that the coordinate system for the feff.inp file (and,
so the POLARIZATION card) is such that X, Y, Z listed in feff.inp are along
the A, B, and C crystallographic directions of the original
crystallographic description?  I think the original post here was noticing
that this was not always the case, and Bruce confirmed that this was not
always the case.

Was it ever guaranteed to be the case that XYZ in the feff.inp file was
along the original crystallographic axes?   I honestly don't know.  It does
seem like a decent convention to use, and I'd be surprised to see the
coordinates rotated by an arbitrary rotation matrix, but I can believe that
some structures could end up being rotated by 45 or 60 degrees from the
ones specified in the CIF or Atoms file.

The POLARIZATION card goes in the feff.inp file, not in the atoms.inp file,
and the original crystallographic description of the structure is pretty
much lost at that point -- feff.inp contains a cluster of atom, not a
crystal structure. The POLARIZATION card has to be relative to the cluster
of atoms listed.

--Matt Newville
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Bruce Ravel]

Robert,

You have me confused.  You seem to be saying that using the correct 
space group symbol is important.  I couldn't possibly disagree.


Raj's original question had to do with the fact that two different 
versions of atoms, which used different algorithms for interpreting the 
crystal data, resulted in clusters that were rotated relative to one 
another.  My answer, appropriate (I think) in that case, was to shrug.


You seem to be commenting on something unrelated to the original 
question, but I'm not understanding the point.


B

On 12/21/2016 01:13 PM, Robert Gordon wrote:

Hi Bruce,

The atoms.inp file attached is for bct Fe. In symmetry I4/mmm, the
resulting feff input has the coordinates
rotated, while in Immm the resulting coordinates are not rotated
relative to the crystal axes (i.e. in Immm
the 2nd near neighbour is obvious as a lattice constant away in each
direction).

So, with no polarization, the results for scattering paths are the same
(using CRITERIA default), as expected
Path #
Degen
Reff
Scattering Path
Type
Rank I4/mmm
Rank Immm
1
8
2.48
fe1
ss
100
100
2
4
2.835
fe2
ss
37.56
37.56
3
2
2.92
fe3
ss
17.59
17.59
4
16
3.897
fe1-fe1
ms
3.42
3.42
5
32
3.897
fe1-fe2
ms
12.83
12.83
7
16
3.94
fe1-fe3
ms
6.37
6.37


Now consider with  POLARIZATION 1 0 0 (and 1 1 0 for I4/mmm)

#
Degen
Reff
Scatt. Path
Type
I4 1 0 0
I4 1 1 0
Im 1 0 0

4
2.48
fe1
ss
100



4
2.48
fe1
ss
7.89



8
2.48
fe1
ss

100
100

4
2.835
fe2
ss
55.45



2
2.835
fe2
ss

62.05
62.05

16
3.897
fe1-fe1
ms
4.41
9.90
15.43

16
3.897
fe1- fe2
ms
19.03
21.58
21.59



For that first multiple scattering path, the scattering angles are
36.1/90 for I4(1 0 0), 55.1/55.1
for I4(110) and for Im(100) they are 55.1/124.9. The ranking of this
path is not the same,
and the plots for this path differ as well - in shape as well as amplitude.

Conceptually, the Immm model calculation has the atoms aligned with the
crystal lattice
and the I4/mmm has the atoms rotated. FEFF sees a difference, and I
would take
the Immm result as the correct one based on the positions of the atoms
in the cluster
relative to the axes.

-R.


On 12/21/2016 6:49 AM, Bruce Ravel wrote:

On 12/19/2016 11:01 PM, Robert Gordon wrote:

What if one were to do this FEFF calculation using the POLARIZATION
card?
1 0 0 means something different if the atom positions have been rotated
by 45 degrees relative to the crystal axes along which the polarization
is defined.


Well ... you could rotate the polarization vector by 45 degrees ...

I guess I have always considered FEFF's polarization card to be an a
posteriori addition to the feff.inp file -- i.e. a decision that the
user makes after using Atoms to convert crystal data to a cluster in
feff.inp.

B





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




--
 Bruce Ravel   bra...@bnl.gov

 National Institute of Standards and Technology
 Synchrotron Science Group at NSLS-II
 Building 743, Room 114
 Upton NY, 11973

 Homepage:http://bruceravel.github.io/home/
 Software:https://github.com/bruceravel
 Demeter: http://bruceravel.github.io/demeter/
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Robert Gordon]

Hi Bruce,

The atoms.inp file attached is for bct Fe. In symmetry I4/mmm, the 
resulting feff input has the coordinates
rotated, while in Immm the resulting coordinates are not rotated 
relative to the crystal axes (i.e. in Immm
the 2nd near neighbour is obvious as a lattice constant away in each 
direction).


So, with no polarization, the results for scattering paths are the same 
(using CRITERIA default), as expected

Path #
Degen
Reff
Scattering Path
Type
Rank I4/mmm
Rank Immm
1
8
2.48
fe1
ss
100
100
2
4
2.835
fe2
ss
37.56
37.56
3
2
2.92
fe3
ss
17.59
17.59
4
16
3.897
fe1-fe1
ms
3.42
3.42
5
32
3.897
fe1-fe2
ms
12.83
12.83
7
16
3.94
fe1-fe3
ms
6.37
6.37


Now consider with  POLARIZATION 1 0 0 (and 1 1 0 for I4/mmm)

#
Degen
Reff
Scatt. Path
Type
I4 1 0 0
I4 1 1 0
Im 1 0 0

4
2.48
fe1
ss
100



4
2.48
fe1
ss
7.89



8
2.48
fe1
ss

100
100

4
2.835
fe2
ss
55.45



2
2.835
fe2
ss

62.05
62.05

16
3.897
fe1-fe1
ms
4.41
9.90
15.43

16
3.897
fe1- fe2
ms
19.03
21.58
21.59



For that first multiple scattering path, the scattering angles are 
36.1/90 for I4(1 0 0), 55.1/55.1
for I4(110) and for Im(100) they are 55.1/124.9. The ranking of this 
path is not the same,

and the plots for this path differ as well - in shape as well as amplitude.

Conceptually, the Immm model calculation has the atoms aligned with the 
crystal lattice
and the I4/mmm has the atoms rotated. FEFF sees a difference, and I 
would take
the Immm result as the correct one based on the positions of the atoms 
in the cluster

relative to the axes.

-R.


On 12/21/2016 6:49 AM, Bruce Ravel wrote:

On 12/19/2016 11:01 PM, Robert Gordon wrote:
What if one were to do this FEFF calculation using the POLARIZATION 
card?

1 0 0 means something different if the atom positions have been rotated
by 45 degrees relative to the crystal axes along which the polarization
is defined.


Well ... you could rotate the polarization vector by 45 degrees ...

I guess I have always considered FEFF's polarization card to be an a 
posteriori addition to the feff.inp file -- i.e. a decision that the 
user makes after using Atoms to convert crystal data to a cluster in 
feff.inp.


B



## This Atoms file was generated by Demeter 0.9.25
## Demeter written by and copyright (c) Bruce Ravel, 2006-2016

title = fe foil
space = I m m m
a =   2.83500b=   2.83500c =   2.92000
alpha =  90.0beta =  90.0gamma =  90.0
rmax  =  10.0core  = fe
 # polarization = 0.0  0.0  0.0
shift = 0.00.00.0
atoms
# el. x   y   ztag
  Fe 0.0 0.0 0.0   fe
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Ifeffit Digest, Vol 166, Issue 12

[Bruce Ravel]

On 12/19/2016 11:01 PM, Robert Gordon wrote:

What if one were to do this FEFF calculation using the POLARIZATION card?
1 0 0 means something different if the atom positions have been rotated
by 45 degrees relative to the crystal axes along which the polarization
is defined.


Well ... you could rotate the polarization vector by 45 degrees ...

I guess I have always considered FEFF's polarization card to be an a 
posteriori addition to the feff.inp file -- i.e. a decision that the 
user makes after using Atoms to convert crystal data to a cluster in 
feff.inp.


B

--
 Bruce Ravel   bra...@bnl.gov

 National Institute of Standards and Technology
 Synchrotron Science Group at NSLS-II
 Building 743, Room 114
 Upton NY, 11973

 Homepage:http://bruceravel.github.io/home/
 Software:https://github.com/bruceravel
 Demeter: http://bruceravel.github.io/demeter/
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit