| Age | Commit message (Collapse) | Author |
|---|
|
Previously, they all wrote into the same "mille-data" folder,
overwriting each others' files and causing general carnage.
|
|
|
|
This allows the user to re-run any job, if they want, or at least easily
use the GUI's work as a template.
|
|
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/87
|
|
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.
|
|
|
|
This is no longer needed after 48c02e71e5bf. Simply set the correct
PATH before starting the GUI, and it will be propagated to the SLURM
jobs.
Astute readers will notice that the feature has been silently broken
since last March (65a1afdce2da5cd), anyway. Whoops.
|
|
Unfortunately, several environments rely on "magic" environment
variables to make things work. These need to be propagated.
The path to the GUI will no longer be added to the PATH. This was
intended to help when the indexing executables (mosflm, dirax etc) were
found alongside the CrystFEL executables. However, it's highly likely
that the path to the CrystFEL executables will be in PATH anyway.
This way, running the SLURM jobs in the same environment as the GUI
itself, also seems more compliant with the "principle of least
surprise".
|
|
|
|
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/49
|
|
|
|
|
|
|
|
|
|
|
|
This requires changing all the paths to relative ones.
Previously, the jobs ran with their CWDs set to the corresponding
"result" folder. The trouble is, this breaks everything that uses a
relative location: image filenames, mask/satmap files referenced by the
geometry, etc.
Note that this change also means that the temporary folders
("indexamajig.XXX") are now produced in the top-level working directory.
Eventually, a GUI option should be added to allow these folders to be
put somewhere better (i.e. somewhere fast).
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/44
|
|
Only when using PinkIndexer.
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/25
|
|
|
|
|
|
This allows project folders to be relocated more easily.
At the same time, I fixed the weird ownership semantics of
add_indexing_result and add_merge_result.
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/31
|
|
|
|
|
|
|
|
The API for cancelling a job seems to be Complicated. The source code
for scancel is nearly a thousand lines long! The API also seems to have
just changed. So, let's just run scancel and be done with it.
|
|
They should start from 1, not 0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This simplifies the backends somewhat, and makes them look more similar
- e.g. there is now only one routine to find out how far along a merging
job is. It has the added bonus of adding a log file for local jobs,
which we would've had to add soon anyway.
|
|
|
|
Whoops.
|
|
|
|
|
|
|
|
Because shortly we will have merging_result as well
|
|
|
|
|
|
|
|
|
|
|
|
|
