CrystFEL issueshttps://gitlab.desy.de/thomas.white/crystfel/-/issues2024-03-01T13:39:41+01:00https://gitlab.desy.de/thomas.white/crystfel/-/issues/92Write a single Millepede file2024-03-01T13:39:41+01:00Thomas WhiteWrite a single Millepede fileAt the moment, we create one Millepede file per indexamajig worker process. That gets multiplied by the number of indexamajig jobs running across the cluster. This results in **thousands** of files, which is not nice for the filesystem...At the moment, we create one Millepede file per indexamajig worker process. That gets multiplied by the number of indexamajig jobs running across the cluster. This results in **thousands** of files, which is not nice for the filesystem or for humans to keep track of. It would be better to combine the Millepede data into a single file for each run of indexamajig. It could be done in a similar way to how the streams get combined from each worker process.CrystFEL 0.12.0https://gitlab.desy.de/thomas.white/crystfel/-/issues/80Faster reflection prediction2024-01-02T15:30:38+01:00Thomas WhiteFaster reflection predictionCrystFEL is currently using a naive brute force algorithm, looping over all reflections to determine which ones are excited. There are at least two better algorithms available:
1. Region growing algorithm from Wolfgang Brehm. See [thi...CrystFEL is currently using a naive brute force algorithm, looping over all reflections to determine which ones are excited. There are at least two better algorithms available:
1. Region growing algorithm from Wolfgang Brehm. See [this paper](https://doi.org/10.1107/S2053273323000682) (appendix B). Preliminary work on branch [region-growing](https://gitlab.desy.de/thomas.white/crystfel/-/commits/region-growing).
2. Quadratic limits algorithm from G. N. Reeke. Mentioned in [this paper](http://scripts.iucr.org/cgi-bin/paper?gm5043) (end of section 9.2) which references a paper in one of the old LURE reports (difficult to find, but Tom has the PDF).
Slow prediction motivated the addition of `--cell-parameters-only` in 46baa4da52b939db5e8a01271befb9f5e704b3b7. For online cell monitoring, no prediction is obviously the fastest possible solution. Nevertheless, there's a big speed improvement to be made here.CrystFEL 0.12.0https://gitlab.desy.de/thomas.white/crystfel/-/issues/57HDF5 peak lists with online data2024-01-02T15:31:07+01:00Thomas WhiteHDF5 peak lists with online dataAs noted in the [documentation for online data](https://gitlab.desy.de/thomas.white/crystfel/-/blob/master/doc/articles/online.rst), `--peaks=hdf5` cannot yet be combined with online data from ZMQ or ASAP::O. This is because `image_read...As noted in the [documentation for online data](https://gitlab.desy.de/thomas.white/crystfel/-/blob/master/doc/articles/online.rst), `--peaks=hdf5` cannot yet be combined with online data from ZMQ or ASAP::O. This is because `image_read_peaks` (and descendants) take a filename. This needs to be generalised to handle a data block.CrystFEL 0.12.0https://gitlab.desy.de/thomas.white/crystfel/-/issues/39Work out correct lattice type and unique axis after cell transformation2021-05-17T11:51:33+02:00Thomas WhiteWork out correct lattice type and unique axis after cell transformationCurrently, `cell_transform_rational` just marks the output cell as triclinic with unknown unique axis. It should be possible to algebraically work out the real lattice type and unique axis. No cheating by comparing axis lengths and ang...Currently, `cell_transform_rational` just marks the output cell as triclinic with unknown unique axis. It should be possible to algebraically work out the real lattice type and unique axis. No cheating by comparing axis lengths and angles, because that's not very general. A general solution is probably worth a paper.https://gitlab.desy.de/thomas.white/crystfel/-/issues/10Retrieve values from CBF headers2021-04-27T14:43:00+02:00Thomas WhiteRetrieve values from CBF headersCurrently, metadata retrieval, e.g. for the X-ray wavelength, only works from HDF5 fields and stream input. CBF should be added to this list. This is more difficult than it seems, because CBF headers are a bit of a messy mixture of pro...Currently, metadata retrieval, e.g. for the X-ray wavelength, only works from HDF5 fields and stream input. CBF should be added to this list. This is more difficult than it seems, because CBF headers are a bit of a messy mixture of properly formatted CIF headers and blocks of custom Dectris headers (with various inconsistent labels). There'd need to be some way of defining exactly where a value should come from.
Although it's a big omission, surprisingly no-one seems to be asking for this feature at the moment. Therefore it's kind of lower priority. Disagree? Comment here.