Hi Bruce, 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. -R. On 12/16/2016 10:14 AM, Bruce Ravel wrote:

On 12/16/2016 12:55 PM, Raj kumar wrote:

...

Thanks for the explanation. Yes, both files are generating the same kind of output but the positioning of atoms can mislead in the context of structure. That's why i have raised the question.

Hi Raj,

But they are /the/ /same/ structure, so they give the same XAFS results, which is the problem that all the versions of Atoms intend to solve. Again, I don't think there is anything wrong that needs my attention.

Cheers, B

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

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.00000 0.00000 0.00000 0 fe 0.00000 1.43300 1.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 -1.43300 -1.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 1.43300 -1.43300 -1.43300 1 fe.1 2.48203 -1.43300 -1.43300 -1.43300 1 fe.1 2.48203 2.86600 0.00000 0.00000 1 fe.2 2.86600 -2.86600 0.00000 0.00000 1 fe.2 2.86600 0.00000 2.86600 0.00000 1 fe.2 2.86600 0.00000 -2.86600 0.00000 1 fe.2 2.86600 0.00000 0.00000 2.86600 1 fe.2 2.86600 0.00000 0.00000 -2.86600 1 fe.2 2.86600 and if one drops to tetragonal symmetry, same cell, same contents, just using lower symmetry for s&g, one obtains 0.00000 0.00000 0.00000 0 fe 0.00000 2.02657 0.00000 1.43300 1 fe.1 2.48203 -2.02657 0.00000 1.43300 1 fe.1 2.48203 0.00000 2.02657 1.43300 1 fe.1 2.48203 0.00000 -2.02657 1.43300 1 fe.1 2.48203 2.02657 0.00000 -1.43300 1 fe.1 2.48203 -2.02657 0.00000 -1.43300 1 fe.1 2.48203 0.00000 2.02657 -1.43300 1 fe.1 2.48203 0.00000 -2.02657 -1.43300 1 fe.1 2.48203 2.02657 2.02657 0.00000 1 fe.2 2.86600 -2.02657 2.02657 0.00000 1 fe.2 2.86600 2.02657 -2.02657 0.00000 1 fe.2 2.86600 -2.02657 -2.02657 0.00000 1 fe.2 2.86600 0.00000 0.00000 2.86600 1 fe.2 2.86600 0.00000 0.00000 -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.00000 0.00000 0.00000 0 fe 0.00000 1.43300 1.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 -1.43300 -1.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 1.43300 -1.43300 -1.43300 1 fe.1 2.48203 -1.43300 -1.43300 -1.43300 1 fe.1 2.48203 2.86600 0.00000 0.00000 1 fe.2 2.86600 -2.86600 0.00000 0.00000 1 fe.2 2.86600 0.00000 2.86600 0.00000 1 fe.2 2.86600 0.00000 -2.86600 0.00000 1 fe.2 2.86600 0.00000 0.00000 2.86600 1 fe.2 2.86600 0.00000 0.00000 -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 aside), confusion is less-likely? -R. On 12/21/2016 10:51 AM, Bruce Ravel wrote:

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

Hi Bruce, Has this changed since you wrote the dos variant of the program? I still have atoms.exe version 2.46b that came with FEFF7 and when I try the same bcc-bct-bco calculations of the Fe cell the results don't vary. Even the tetragonal version remains aligned to the axes. -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/spa...

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

Robert, It seems you are sort of cherry picking through the code. When I first wrote Xray::Crystal, I spent a lot of time pouring over chapter 5 of ITC volume A. I am mostly confident that the various transformations are applied correctly in response to space group symbol choices. Demeter does that by applying a transformation to place the positions under the alternate symbol onto the setting of the standard symbol (*) then transforms back after applying symmetry operations. Again, my goal was to build the cluster correctly but without concern for alignment to a particular set of axes. None of this is to say that I do not welcome actionable bug reports, but emphasis is on the "actionable". B (*) "Standard" means "has an entry in chapter 7 of ITC Volume A", as opposed to being tabulated in Chapter 4. Atoms tried to recognize all the symbols in Chapter 4, but it transforms coordinates to the standard settings before applying symmetry operations. Obviously, a program like Atoms need not work that way. It could simply apply symmetries encoded in any symbol from Chapter 4. But Atoms does what I described. On 12/21/2016 08:22 PM, Robert Gordon wrote:

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/spa...

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

-- Bruce Ravel ------------------------------------ bravel@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/