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