---
name: DIALS core meeting 2021-07-15
tags: core meeting
---

# DIALS core meeting 2021-07-15

[](https://hackmd.io/AaGHp7gKQ-6m-YnCinO8ew)
[Previous meeting: [2021-07-01](https://dials.github.io/kb/core/20210701)]

## Previous Actions

* [x] MG: Giving a [typing intro lecture](https://dials.github.io/kb/core/2020917#typing-mypy) on 14th of July, 13:00 BST
* [ ] [dx2 proposal](https://dials.github.io/kb/core/20210128#dx2-proposal)
* [ ] MG to put in a PR to create a proposal in the proposal-space
* [ ] MG+ND: Come up with a proposal to [move away from all code being in header files](https://dials.github.io/kb/core/20201001#overall-architecture-discussion) and consolidate into a single library
* [ ] **Action**: Agreed the process was useful. Shelve and come back in three months, see what everyone's time looks like
* [x] Merge dxtbx `src/` layout change ([prev](https://dials.github.io/kb/core/20210701#src-layout-for-dxtbx))
* [ ] ND: conda-forge pycbf: Make new release to use dials-data directly for tests

## Agenda

### Status checks before merging on `dials/dials`
- Agreed previously on [2021-06-17](https://dials.github.io/kb/core/20210617#status-checks-before-merging)
- Review planned for 2021-07-15
- What have peoples experiences of this been?
- Everyone happy

### "Contiguous Nexus" PR
- [`cctbx/dxtbx#356`](https://github.com/cctbx/dxtbx/pull/356)
- What is status of this?
- Raised internally whether this would benefit from flumpy conversions? Is numpy bypassed entirely already?
- **Action**: Non-draft pending checks against the possible issues that @dwpaley has raised, and checking for no-contiguous cases

### [cbflib conda-forge package/pycbf](https://dials.github.io/kb/core/20210520#cbflib-conda-forge-package)

* Outstanding: [dxtbx#368](https://github.com/cctbx/dxtbx/pull/368) for optional usage in dxtbx, no binary dependence on cbflib/_adaptbx if present.
* Still stray issue with dataset `SPring8_ADSC_SN916` being the only one requiring `FormatCBFFull`. One possible solution is adding a special Format: [`dials/dials#366`](https://github.com/cctbx/dxtbx/pull/366)
* Still need to test with `labelit`/`labelit_regression` once the test suites actually work
* All except one labelit tests are now working. On NKS todo list to fix.
* CBFlib 0.9.7 work is ongoing at [`cbflib/cbflib#1`](https://github.com/cbflib/cbflib/pull/1). Tests now pass.

### `src/` layout for dxtbx
- Once 2021.06 July release is out ~~[`cctbx/dxtbx#382`](https://github.com/cctbx/dxtbx/pull/382)~~ **Merged**.
- Outstanding issue: [`cctbx/dxtbx#393`](https://github.com/cctbx/dxtbx/issues/393) - dispatcher re-export of non-dxtbx tooling appears not to work on Windows
- **Action**: Ask CCTBXBB if anyone has knowledge or experience of this behaviour

### flumpy -- flex/numpy bridge
- ~~[`cctbx/dxtbx#377`](https://github.com/cctbx/dxtbx/pull/377)~~ **Merged**
- Tests failed on Windows: ~~[`cctbx/dxtbx#392`](https://github.com/cctbx/dxtbx/issues/392)~~ - Flex doesn't bind C `long long` on any platform, but On POSIX platforms `long` and `long long` are both 64 bit integers, and `numpy` tends to pass `"q"` [codes](https://numpy.org/doc/stable/reference/arrays.scalars.html#numpy.longlong) for any 64-bit integer dtype. On Windows, flex still doesn't bind `long long` but _does_ bind `int64_t` (64-bit unsigned is bound as `size_t`) which matches the `"q"` dtype.
- Additional problem: [`cctbx/dxtbx#398`](https://github.com/cctbx/dxtbx/issues/398) `from_numpy` currently fails if `scitbx.array_family.flex` has not already been imported.

### DIALS versions in Phenix releases

- Short discussion about the development branch of CCTBX pointing to old dials builds, is all clear now

### Nonconventional P1 indexing

- D: Observed that indexing in P1 with b>c in a non-conventional settings appears to break (in stills_process, dials.index to be checked)
- stills_process might not process triclinic cells in an unconventional settings - possibly tries to order base vectors?
- Should this be indexing in the lattice that you give it, rather than changing the setting?
- **Action**: Dan to try and demonstrate this on a simple/lysozyme example and file an issue

### Next meeting
Thursday, July 29th, 4pm UK (BST), 8am PDT.