DIALS core meeting 2022-06-23
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.
Pre-material
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?
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-data updates
Merged in meetingdials/data-files#42
New file PR- Corresponding dials-data updates https://github.com/dials/data/pull/375/files - squash merged
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
DIALS Conda-Forge
- SEGV problems known with
wx
on the alpha package @nickd now fixed? - Possibly Billy has encountered and fixed such a problem, Aaron will make enquiries
- Fixed for next DIALS 3.10 release following bug fix
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.
Next meeting
Thursday, July 7th, 4pm (BST), 8am (PDT)