Age | Commit message (Collapse) | Author |
|
|
|
I was trying to be too clever. The old version breaks if the G6
distance is exactly zero, which happens e.g. in one of the unit tests.
|
|
The previous behaviour gave biased cell distributions in some
situations, because it preferred not to overrule the indexing algorithm.
Some indexing algorithms (xgandalf) always return a certain cell
variant, e.g. gamma > 90. To make the histograms interpretable, we have
to randomise our choice of reduced cell in all cases.
However, we need to be careful that the cells we randomise between are
really equivalent. The previous behaviour here was to look only at the
axis lengths. We must look at the angles as well.
But that's not the end of the story. We would have to choose some
weighting factor between axis lengths and angles when deciding if a new
cell is "better". That would be hard. Instead, compare_rcp now
compares the G6 vectors directly, which consider lengths and angles on
an even footing.
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/95
|
|
|
|
|
|
|
|
|
|
|
|
Prompted by the article linked below, for each FIXME/TODO I've either
referenced an issue in the tracker, or removed it if it's not worth
fixing.
https://schleiss.io/plotting-source-code-todos-for-open-source-projects
|
|
|
|
This removes the big potential for confusion, which has happened several
times (see e.g. 095cbebaf6). It also fixes in-tree builds with CMake
(but seriously, always use out-of-tree builds).
Fixes #2.
|
|
|
|
This avoids a load of trigonometric functions. In combination with the
new UnitCell representation caching, this gives a significant speedup
for cases where resolution() is called in a loop.
|
|
Previously, the "getter" functions would re-calculate the requested
representation every time they were called. This could mean doing a
matrix inversion in the middle of a tight loop, wasting loads of time.
Now, it stores the calculated values and returns them directly next
time. Setting the parameters invalidates the values for all
representations other than the one given.
The cost of doing this is that the cell can no longer be "const" in the
getter functions. This tracked through some other code, but nothing too
severe.
|
|
The criterion for "too large" is 20% of the 1/d value for the lowest
reflection which is not systematically absent according to the
centering.
A profile radius larger than the 1/d value for a reflection will crash
the xsphere partiality model, and some visualisation shows that this is
a clearly non-physical situation. The profile radius shouldn't be
anywhere near the inter-Bragg spacing for reasonable data.
However, feedback shows that this is happening quite often in real data,
probably due to bad indexing.
|
|
I'm sick of fixing this same issue over and over again.
New rule: any code handling unit cell tolerances MUST be labelled with
details of units.
|
|
See 0f18ff76a3d1f5979db for some discussion.
|
|
|
|
|
|
|
|
|
|
Otherwise, the cell comparison doesn't recognise the cells as the same,
breaking indexing with an R reference cell.
Unfortunately, the resulting cell after comparison by compare_r_c_p
still comes out as P, but that doesn't seem like a big loss. To get it
strictly correct, we'd need some way of tracking through the information
that the cell got "uncentered" from R to P, even though the matrix is an
identity.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
permutation check
More than 5 possible when there are axes with similar lengths.
|
|
|
|
|
|
compare_reindexed_cell_parameters still needs to be updated
|
|
|
|
|
|
|
|
|
|
|
|
Especially, remove the last ltl/atl tolerance values.
|
|
|
|
|
|
|
|
|
|
Doesn't work yet
|
|
|
|
|
|
|
|
|
|
tolerances
|
|
|
|
|