--- name: DIALS core meeting 2021-07-15 tags: core meeting --- # DIALS core meeting 2021-07-15 [![hackmd-github-sync-badge](https://hackmd.io/AaGHp7gKQ-6m-YnCinO8ew/badge)](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.