| Age | Commit message (Collapse) | Author |
|---|
|
Previously, there was a bad bug here. We would still try to write a
top-level coffset even if panels have moved such that the coffset is no
longer a single value.
One possibility is to unset panel->cnz_offset_default when moving a
panel. This works, but we have to do it on every translation, or accept
a floating-point comparison with zero and associated non-determinism.
It's very likely that if we move one panel, we'll be moving all panels,
even if only by a small amount. So, a more stable way seems to just
write separate coffset values all the time. The coffset values aren't
really meant to be used at the top level anyway (that's what clen is
for!), so this fits pretty well.
|
|
Two problems:
1. Didn't take into account that bad->name already includes the prefix
"bad".
2. Didn't convert the panel-relative coordinates back to slab-relative.
Fixes: https://github.com/taw10/crystfel/issues/11
|
|
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/96
|
|
|
|
Also mention this when complaining about the geometry file.
Fixes: https://github.com/taw10/crystfel/issues/10
|
|
Fixes: https://github.com/taw10/crystfel/issues/9
|
|
In some rare cases, the cell changes from right to left handed during
the vector refinement stage of asdf, while ending up at an apparently
correct indexing solution. This commit just flips the axis round when
necessary, in the same way that asdf already does in an earlier stage.
I haven't done a proper survey, but I can say that the image I used to
isolate and test this issue had very low resolution while still being
what we would call "indexable". The left-handed cells appeared for six
out of the 12173 hits in that run, or slightly below 0.05%. So, it's
rare but not totally impossible.
|
|
It's hardly needed for re-use, and invites problems with the volume
going out of sync with the vectors. Better just to calculate it when
needed.
|
|
|
|
|
|
This avoids having to awkwardly pass the wavelength separately, e.g. to
the polarisation correction.
|
|
This was missed out, causing DataTemplates to be written incorrectly.
|
|
|
|
|
|
Previous commit a6462e1f0 was still not right. If the image gets freed,
the PeakList can be left with a dangling reference. If the peak list
gets replaced at the C level (e.g. by running a new peak search), Julia
will have no way of knowing about it.
Instead of having the PeakList know if it's associated with an image,
it's better to have the Image know (at the C level) if it's responsible
for freeing the ImageFeatureList. As soon as the ImageFeatureList is
exposed to the Julia GC via a PeakList object, it becomes Julia's
responsibility to free it. The Julia Image structure contains a
reference to the Julia PeakList, to prevent this from happening until
either the image is freed or a new PeakList is substituted. The two
references (Julia image.peaklist and C image->features) have to be kept
in sync, and we check image->features every time the peaklist is
requested.
|
|
|
|
This enables early exit from iteration over a RefList.
|
|
This changes all the peak search procedures into pure functions that
return a new ImageFeatureList. This takes the management of
image->features out of the hands of the peak search routines, and into
the calling code's responsibility.
In turn, this allows a load of stuff to become const.
|
|
|
|
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
|
