[Ifeffit] Ifeffit Digest, Vol 166, Issue 12

Bruce Ravel bravel at bnl.gov
Thu Dec 22 08:39:52 CST 2016


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/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 at 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 at 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/


More information about the Ifeffit mailing list