Age | Commit message (Collapse) | Author |
|
Same deal as 6ead0af32.
|
|
|
|
This has a cleaner background, and the window icon has been fixed (see
ad8494c441231).
|
|
This commit strips out all references to the Slurm API, instead making
subprocess calls to sbatch and scontrol.
Attempting to use the Slurm API seems to have been a mis-step. First,
it seems that nowhere has the Slurm headers pre-installed. Literally
none of the facilities where there are known deployments of CrystFEL
have them. And in a significant fraction of cases, getting them
installed is difficult, slow or impossible.
In addition, the API doesn't seem to work in all cases, so we already
shell out to 'scancel' to abort jobs - see d76fc3495.
There are some tricky implications for submitting Slurm jobs from a
container via the API. The Slurm REST API offers a solution, but is
very new and not widely available. Calls to the Slurm executables are
much easier to 'tunnel' out of a container.
This isn't a great solution. It's a net increase of only about 40 lines
of source code, but it incurs some unpleasant string handling and will
probably be less reliable overall. It completely relies on Slurm's not
being internationalised. If Slurm's messages start getting translated,
we will be in trouble.
|
|
|
|
The csplit format is ambiguous when the filenames contain spaces. To
make things a bit clearer, the file now requires the fields to be
separated by exactly one space rather than any number of tabs/spaces.
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/55
|
|
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/27
|
|
This got missed out by accident in the conversion to DataTemplate, but
absolutely no-one noticed. In the meantime, my views on how the
geometry files should work have changed somewhat. I don't want to
maintain the extra complexity here when it isn't even clear that it will
eliminate the need to re-refine geometry for each camera length.
This commit just takes the rail direction stuff out of the documentation
and the geometry file parser.
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/50
|
|
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/52
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This (re-)adds the ability to get data via a request/reply socket.
See afcb7b568947c for when it was removed.
|
|
|
|
|
|
|
|
|
|
|
|
This removes some unnecessary work (getting the address from the file)
and seems cleaner.
|
|
|
|
Unfortunately, PinkIndexer needs the real camera length for its centre
refinement. Giving a fake value and scaling the resulting shift does
not work - the indexing rate drops with even a small error.
Ideally, this would work in the same way as --wavelength-estimate, by
using a static value from the geometry file if it's given. However,
this is rather complicated to implement because of the way all the units
stuff is implemented. Therefore, this is left as an improvement for the
future.
|
|
|
|
This is a more general replacement for --pinkIndexer-thread-count.
|
|
This will return later in a more centralised form, if we decide to work
further on wide bandwidth.
|
|
These conflict badly with CrystFEL's own checks, creating a horrible
user and developer experience.
Later, if we want to handle wide bandwidth beams, we will improve the
central CrystFEL checks to support it.
|
|
This is a more sensible non-indexer-specific and non-Xray-specific
replacement for --pinkIndexer-override-photon-energy
|
|
|
|
No-one uses it, it doubles the complexity of the code, and the manual
even warns not to use it.
|
|
The tiny amount of information in that file isn't relevant (or even
correct..) any more.
|
|
|
|
|
|
|
|
This makes handling Pilatus/Eiger files, as well as many others, much
easier.
|
|
|
|
|
|
|
|
|
|
|
|
|