[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
>
>
>