David Waterman

Results 198 comments of David Waterman

`cctbx.multiplicity_viewer` is a nice viewer for this, but it only works on MTZ files. Meanwhile, we have `dials.indexed_as_integrated`, but that only works for single experiments. Nevertheless, for fun: ``` dials.split_experiments...

Test coverage for these files today: - [crystal_parameters.py](https://codecov.io/gh/dials/dials/src/master/algorithms/refinement/parameterisation/crystal_parameters.py): only an `except` block is not covered - [prediction_parameters.py](https://codecov.io/gh/dials/dials/src/master/algorithms/refinement/parameterisation/prediction_parameters.py): corner cases for experiments with no reflections, handling of `None` derivatives and `except`...

I don't understand the test failures here. Doesn't happen locally and seems to be nothing to do with this PR :thinking:

One issue is determining the layout of panels. The fairly dumb way that `dev.dials.plot_detector_shifts` handles the problem is to guess it based on number of panels, pixel size and panel...

This is an old one for I23 ![normal_diff](https://cloud.githubusercontent.com/assets/11502083/22826955/1fa17ba4-ef8d-11e6-94f0-ab6879cfe67b.png) I23 is the special-special case, in which using the lab space geometry like `dev.cctbx.xfel.detector_residuals` possibly breaks down. Otherwise, I like that approach....

P6M example ![normal_diff 1](https://cloud.githubusercontent.com/assets/11502083/22827064/d44ad956-ef8d-11e6-8604-25fb90869479.png) The other way you can do it is using spherical polars, which works in general for any detector, but the distortion looks weird. ![sp_normal_diff](https://cloud.githubusercontent.com/assets/11502083/22827110/08d466ce-ef8e-11e6-886f-a5c667f33728.png) I imagine...

Something we talked about at the last DIALS East group meeting was having each detector model define its own layout for display, for plots like these and for image viewers....

See also discussion here https://github.com/dials/dials/issues/1358#issuecomment-664853641

NB overlaps handling in DIALS actually appears to be broken, at least to some extent https://github.com/dials/dials/issues/1890

It should be possible to predict the amount of RAM required just ahead of gradient calculation here: https://github.com/dials/dials/blob/master/algorithms/refinement/parameterisation/prediction_parameters.py#L302. At this point the number of reflections and the number of parameters...