| Age | Commit message (Collapse) | Author |
|---|
|
This also gets rid of crystal_copy_deep. From now on, all crystal_copy
calls also copy the UnitCell.
|
|
This fixes the general prediction/partiality parts.
|
|
This fixes integration.c, peaks.c and process_hkl.c.
|
|
This commit replaces image.crystals with an array of small structs, each
consisting of a Crystal-RefList pair. index.c and stream.c are updated,
more to follow.
|
|
This is a terrible bit of API. A Crystal contains both the parameters
for a calculation (e.g. prediction) and the results. Just look at
post-refinement.c for an example of the mess this makes when trying to
do calculations.
This commit removes the reflection list from the Crystal structure.
Future commits in this series will fix the resulting build carnage.
This also gets rid of vestigial field pr_dud, and adds initialisers for
all (remaining) fields.
|
|
|
|
|
|
It hasn't been needed for ages.
|
|
|
|
|
|
|
|
A little clearer than fftw_malloc(*sizeof)
|
|
This is only needed to reset FFTW to a "pristine" state, which is not
required here, and possibly even detrimental.
|
|
We don't need to fish out the arrays and use FFTW's "new array
execution" functions: http://fftw.org/fftw3_doc/New_002darray-Execute-Functions.html
|
|
|
|
|
|
There are still some rough edges, e.g. it only works with a simple
I/SIGI column (not I+/I-), and can't yet interpret the symmetry
information in the file. However, it's still better than the old
mtz2hkl script.
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/7
|
|
Example: group_all = q0,q1,q2,q2
|
|
|
|
We noticed that constant freeing and re-allocating the (potentially
quite large) arrays resulted in much lower performance. Since we know
that all images have the same data layout, we can safely re-use the
arrays. This gives a large speedup.
|
|
The saturation array is created by create_satmap when needed, which
takes care that all panels get an array (so we only have to check
image->sat != NULL). The array created by image_create_dp_bad_sat was
actually leaked!
In any case, saturation maps are rarely used. We can do without the
extra allocations.
The routine name has been changed accordingly, to prevent future
confusion.
|
|
The "children" array was the wrong size, and not freed. Also, some
formatting fussiness.
|
|
|
|
These should be get_exerr. Following 1ae9a4582, the r_dev values are no
longer useful physical quantities, only a refinement target function.
This was causing the last few Git versions to not predict any
reflections at all!
|
|
The restraint was way too strong, after the last round of tweaking.
With a weaker restraint, the algorithm converges very quickly - it's
practically linear - so ten iterations is way too much.
|
|
|
|
This avoids weird weighting factors everywhere and much confusion.
Since Millepede doesn't have an easy way of weighting measurements (only
via altering the ESD values), treating it as a units conversion seems to
be easier.
|
|
We want the residual in pixels, as described in the comment for
EXC_WEIGHT.
This routine is only used for displaying the total residuals, not for
the real minimisation maths. However, we need to be clear.
|
|
|
|
|
|
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/3
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/29
|
|
|
|
Should always be a right-hand grip rotation around positive axis
direction.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We need mille_label() for align_detector, even if we don't have
Millepede.
Some of this complexity can be removed later by re-implementing
"mille()". The build system and wrapper code is already longer than a
pure C implementation would be.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The *parameters* will be in metres, radians, m^-1 for translation,
rotation and cell parameters respectively.
The *residuals*, however, are in pixels.
|
|
|
