We normally use xia2 for processing at the beamline. Although xia2 is on conda-forge, it requires ccp4, which means we cannot easily package it in a docker image together with mdx2 and dials.
What would be great is a patch or wrapper around the xia2 dials pipeline that removes any ccp4 dependencies. This should be possible -- a quick look at the code suggests that ccp4 is only used for radiation damage analysis and xtriage in the xia2 html report, and FreeR flags (which could be skipped).
Suggestion: a command-line program mdx2.dials_pipeline that runs the a monkey-patched xia2. The patches would skip the steps that require ccp4 programs, and suppress any errors from ccp4 checks.
In future, we could add some diffuse-specific tasks to the pipeline, such as enforcing a default directory structure, importing background images, and handling multi-crystal data.
We normally use xia2 for processing at the beamline. Although xia2 is on conda-forge, it requires ccp4, which means we cannot easily package it in a docker image together with mdx2 and dials.
What would be great is a patch or wrapper around the
xia2dials pipeline that removes any ccp4 dependencies. This should be possible -- a quick look at the code suggests that ccp4 is only used for radiation damage analysis and xtriage in the xia2 html report, and FreeR flags (which could be skipped).Suggestion: a command-line program
mdx2.dials_pipelinethat runs the a monkey-patched xia2. The patches would skip the steps that require ccp4 programs, and suppress any errors from ccp4 checks.In future, we could add some diffuse-specific tasks to the pipeline, such as enforcing a default directory structure, importing background images, and handling multi-crystal data.