DIALS core meeting 2022-07-07

Previous Actions

• ND to review: TOFBeam - A time-of-flight beam in dxtbx cctbx/dxtbx#492 (prev)
• std::string support for messagepack. This is used in XFEL module, should try to fix. dials/dials#1858.
  • Is using pickle until this is fixed, so probably good to do
• DIALS LTS 3.8 Backporting
  • - Action: Nick: Backport read-only-base fixes for dxtbx and xia2
  • Also, backport read-only fixes for iota
  • ASB to verify that these are done

Agenda

00 NKS detector refinement

Discussion of refinement of detector at two distances with one rigid body model for detector. Want to keep one rigid body model of the detector hierarchy at two bulk positions. Discussion with DGW re: refinement parameterisation.

NKS has data packed up ready for sharing with 10,000 shots.

Observation: a mechanism to compare the relative orientation of panels between two detector models would be useful e.g. with respect to level-0 detector frame.

DGW: you need to set an id to the constraints to set up which experiments are constrained - you need a list of id’s - DGW to correct notes… also discussion of parameterisation, meaning of dist, shift1, … etc.

NKS to share subset of data for this.

• Data has been shared
• DGW has realised a couple of bugs and this is being actively worked on
• Needs parametrisation model to be reworked, DGW thinks is worth doing but can’t look at until the Autumn.

https://github.com/dials/dials/pull/2129

Turns out Dan is using this to adjust the beam centre based on pseudo powder pattern peak widths, so iterating through the reflection list a lot of times -> caches make this better. Need to do this to get a good enough input to allow indexing. Actions -

• Dan to add a short script to execute this calculation so we can reproduce the results, maybe explore an alternative approach
• Richard points out that “skipping panels with no reflections” seems like an easy thing to add in, if separate PR?

Update:

• Is important to do this for LPB at EuXFEL
• Revisit later in the year when the problem is more understood. Possibly reconsider implementation approach to e.g. subclass.

Dropping Data Blocks

https://github.com/cctbx/dxtbx/pull/504

• GW PR
• After PR/PRs, ASB to contact e.g. Mike Wall about this, too.
• GW thinks reasonable to merge when these concerns addressed
• Waiting on AB now, will get sorted as soon as can

LCLS XFEL Updates

• cctbx/dxtbx#517
• GW suggested Ben to have a look
• Action: Add logging to the except Exception: so it doesn’t silently ignore errors
• ASB to turn on tests now dials-data changes below merged
• ASB address DP comments in dials/dials#2110 (I think)

DIALS LTS 3.8

• Phenix pinned to DIALS 3.2
• Action: Nick: Backport read-only-base fixes for dxtbx and xia2
• Action ASB to verify that these are all good
• If all looks good, ASB to talk to Billy about moving DIALS builder to DIALS 3.8 LTS branch
• Discussion of candidates for backporting to DIALS 3.8

AOB?

• Anything “useful” in the main DIALS branch we want in DIALS 3.8 right? DGW, ASB feel that this is the case.
• Discussion of what constitutes a useful change.
• Can we “tag” pull request commits for back port? If we have this then we can reasonably ask that such change sets get back ported.
• DGW look through https://github.com/dials/dials/releases to identify any missing commits - specific mention was reduction in memory use of dials.refine etc.
• See also https://github.com/dials/dials/blob/dials-3.10rc/CHANGELOG.rst

Discussion of whether we could still support Python 3.7. Why can’t CCP4 and PHENIX move to supported versions of Python? PHENIX has a dependency on a package which does not support anything later. Reasoning in CCP4 is very similar, to do with interaction between coot and i2, but there are a list of other reasons. CCDC mogul package is what is holding up PHENIX.

Support is a big commitment.

• DGW test main / 3.10 release branch state against CCP4 base - “DGW this is not possible”
• ASB test main / 3.10 release branch state of DIALS against PHENIX Python 3.7 base

ASB: saw some dxtbx changes which removed 3.7 compatibility -> give up with this exercise.

For future reference: as of today DIALS 3.8 up to .7 patch release -> https://github.com/dials/dials/releases for more details. Not sure why version .5 AWOL, 6, 7 are draft?

ASB: would like to discuss dials.background and noisy pixels -> park on agenda for next meeting. TL;DR - noisy pixels at EU-XFEL, wanted to compare and contrast with find bad pixel code. Confusion: Aaron meant dials.find_bad_pixels. MPI enabling, much lower thresholding. Think already uses future parallels? Adjusting threshold could be useful too.

• Add this as an agenda item for 7th July meeting.
• Add this as an agenda item for 21st July meeting.

Next meeting

Thursday, July 21st, 4pm (BST), 8am (PDT)