DIALS core meeting 2022-11-10
std::stringsupport for messagepack. This is used in XFEL module, should try to fix.
- Is using pickle until this is fixed, so probably good to do
- AB Added to codecamp list. Might get to this!
- Looking at this week. Removing seems acceptable and probably the easiest solution
- AB: Complete coordinate updates (Fix beam center and intensity readout of pixel coordinates)
- GW: Checks to see what affects.
- AB: Make PR for above
- Nick Investigate getting
psanatests running on the DIALS xfel-regression testing
- GW: https://github.com/cctbx/dxtbx/issues/562 - create a one-page summary on projecting resolution rings onto a matplotlib image
- ND: Unpin setuptools in DIALS builds
- AB Met with DmD and Laue-interested groups and was impressed by work
- Derived new classes from the refiner!
- January for resubmitting these to DIALS
- Action: Have meeting about this in new year, want to work out strategy for getting in ASAP in new year
- Got to lots of small improvements
- cctbx-XFEL testing
- Beam center /intensity readout issues
- NXmx equipment components
- Contiguous Nexus (redndant slicing PR)
- Reflection subsampling in stills_process
Dropping Data Blocks
- 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
- Planned time to work on this stuff in October
- Just after branch for 3.12 release of DIALS merge this
- Did this! However… this broke a lot. We reverted and made again, but a bit more complete.
- Currently actively being worked on
Stills to sequences
- dials.import convert_stills_to_sequences=True broken for h5 data - several github issues relating to this (see PR above for links)
- With current dxtbx code, PR does not work for formats that include lazy formats (e.g. SACLA test data), due to an assertion in FormatMultiImage.py: https://github.com/dials/dxtbx/blob/7494dc0332f94c0d4593865f82c7c08a88ae65ea/src/dxtbx/format/FormatMultiImage.py#L215 What is the rationale behind this assertion (developer warning/sanity check?), can it be removed (seems to work fine if removed)?
- Everyone go and reaffirm their understandings and find out what the real reasons/solutions could be
- Important to be able to work on/modify directly in a bootstrap environment, make sure that this can be added as a likewise dependency
- ND: Look at https://github.com/dials/dials/pull/2263
- Planning to merge soon
- Brief discussion on whether this should be added to main dials.index
Thursday, November 24th, 4pm (GMT), 8am (PST)
- No - this is thanksgiving. Next is 8th December.