DIALS core meeting 2026-08-27

Previous Actions

• [~] ND Investigate getting psana tests running on the DIALS xfel-regression testing - do we still care about this or should we drop until xfel is installable via conda-forge

Agenda

PR Slop

• Please, for the love of god, can we stop having slop PR, especially where reading the entire thing takes more time than the lifetime integrated time saved by the actions in the PR.
• If you can’t be bothered to write it, I don’t see why anyone should be expected to read it or review it or spend any time thinking about it (except you are forcing people to think about it by filing the PR).
• Especially when it’s entirely unclear without wading through the whole thing if there is actually any benefit from the PR.
  • See e.g. https://github.com/cctbx/dxtbx/pull/893 where even the submitter didn’t read the output of their own agent, and what looks suspiciously like a reply just copy pasting the results of pasting the comment into their agent.

• It can not be hard to write a paragraph or two of your own copy explaining why the change, why here, and how much time it saves. Or ask Claude to do that.

• GW additional: obliquely related to above commentary but more general - with e.g. the max plan for Claude the opportunity exists to get computer help to go back over some really annoying historical bugs and actually fix them - but the potential cost in reviewing is huge & we need to discuss how we are going to handle these - for example: tackling “dxtbx #719 (get_array_range → get_z_range) is welded to the #186/#716/#717/#718 off-by-one saga — 39 comments on #186 says don’t pull that thread alone”

• Discussion: text of PR should be commensurate with the size of the change set, and the value in the change set should be obvious close to the top of the report (or in an immediate comment further down, with a focus on the end user experience)

ImageSequence rewrite PR

For now drop this and revisit when a new PR made

• Discussion on https://github.com/dials/dials/issues/2377 using ImageSequence in dials.stills_process. Now looking at a scan properties solution. Benchmarking. How long does dials.image_viewer take to open with FormatXTC?
• PR: https://github.com/dials/dials/pull/3181
• General discussion on how to deal with AI generated code changes. Break sweeping Claude changes into small easily reviewed and understood components.
• Still needs eyes

Metrics

• 2025-09-25 - dxtbx-side merged in, nothing yet in DIALS side to push it into the mtz history https://github.com/cctbx/dxtbx/pull/816
• Needs to be work to put in on DIALS side
• Work to do:
  • Need to package history into MTZ, but MTZ history not the right place. Decided MTZ-appendix is the right place to put this in, but work not started yet
  • Aaron has offered Yang’s skills as his work should cover this area
  • Write integrate and scale history to MTZ #2924
  • David to dig relevant information out
• MTZ Appendix: Some controversy
  • Phenix/DIALS not included in discussions
  • Fundamental technological issues
    • Mixing MTZ/CIF
• Gemmi supports
• AB met with BP/DGW/Oleg/Dorothy and talking about MTZ appendix issue
  • Conclusion: Nobody completely happy, AB to approach Clemens and get conversation going
• Dan Paley found issue with profiling and MTZ appendix https://github.com/cctbx/dxtbx/pull/867
  • Agreed looks reasonable
  • Requested David to have a look
  • All agreed, merge after newsfragment
  • Merged!
• AB: To make meeting with Clemens to try to find agreement that we probably need to just go with this
  • Have reached out over email
• Probably a good idea to discuss this with everyone in person in Calgary
• DW feels just missing the MTZ appendix output, feels we are going to have to use it eventually

dials.index with max_lattices >= 2: rejection criteria

• https://github.com/dials/dials/issues/3110 dials.index with max_lattices >= 2: rejection criteria.
  • We think related to known symmetry
  • Wait until Graeme here
• Long discussion about integration memory usage and sample datasets.
• Graeme is here!
• Graeme is going to make efforts to come up with a plan for fixing this
• Interesting discussion about handling of multilattice data
• Graeme is not here today, defer until he is
• Graeme is not here today, defer until he is
• Consensus is this is a good change set? Merge

AOB

We should promote xia2 more

• Reports from workshops that people like autoproc “because it is only one thing to run and not many steps”
• We should promote that xia2 is an option that does this!
• September 20th full day workshop at bay area user meeting
• Some spare budget available if anyone wants to come

DIALS H5 reflection tables

• We should work out a way to move this forward
• Aaron questions performance - we should measure this
• David offers to run over his benchmarking data sets
• Apparently discussed last time - yes this made everything better and faster
• https://github.com/dials/dials/pull/3255

Proof-of-concept slop rewrite of DIALS functionality

• as an exercise worked on Claude over period of 10 days
• import, find spots, index, refine, integrate, symmetry, scale as scope
• spot finding gives same answers, later steps harder to give identical answers
• have a pipeline which can take 1,800 images of Eiger 9M data from import to end scaling in 33s (on laptop) compared with several minutes in DIALS
• results not as good but the overall “shape” is the same => functional goal in terms of timing (and the data are demonstrably correct if not perfect)
• research exercise not aiming to compete with DIALS, only work out a reasonable target

AOAAOB

Dan P to discuss with CCTBX folks about moving off C++14 (auto_ptr for example)

Next meeting

Thursday, September 10th, 4pm (BST), 8am (PDT), 10am (CDT)