DIALS core meeting 2022-07-21

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

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
  • Nick noted new labelling system

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.
• DGW: Changes have gone in, but this is a longer term research problem
  • Detector parametrisation is in an absolute coordinate system, so can’t constrain equivalent parameters between two detector models. Would need a new parametrisation.

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
• Progress!
  • DataBlock in Lunus is one of the outstanding issues
  • AB Identified scripts, Mike Wall agreed that they should be deprecated
  • Extension lunus.stills_process still uses DataBlocks github.com/lanl/lunus@lunus_stills_process.py
  • Probably needs a little bit of work
  • XFEL repos are still WIP
    • ls49
    • cxid9914 (this should be fixed)

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)
• Probably being treated in future planned hackathon

dials.find_bad_pixels

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.

• Shadow goniometer masking is good, but specialised to one use case
• Need more generic so that we can implement in the dxtbx nexus format class
  • ND: Does this mean NXMX?
    • NXMX does have per image mask, but is a per image mask, no way to generate a dynamic mask
• Goniometer masker is only implementation here
• At EuXFEL used LPD detector
  • Detector rotates between four memory banks. Each memory bank has different noise characteristics depending on the gain mode.
  • Would like a way to dynamically calculate a mask depending on bank and gain mode.

AOB?

Next meeting

Thursday, August 18th, 4pm (BST), 8am (PDT)