Skip to content

Always use 352 memory cells for SlopesFF for AGIPD

David Hammer requested to merge agipd-slopesff-352-cells into master

Apparently the constants don't depend on how many memory cells are in use, so it's a big practical benefit to always save just one constant with full set of cells and use it for all operation scenarios. https://git.xfel.eu/calibration/planning/-/issues/107

Here in calng, there are two things to take care of:

  1. When we get a constant file that has more memory cells than others, we need to slice it. That's technically something that we should be doing anyway, so I added it to all constants and also for DSSC and LPD.
  2. We maybe need to query differently for SlopesFF. I included a commit for this (always set memory cells to 352 for SlopesFF). However, if future constants are simply injected with large deviation (https://git.xfel.eu/detectors/pycalibration/-/merge_requests/613), then we can just revert this commit and let the CalCat condition matching sort it out for us.

Addendum to 1: right now, all buffers are initialized to have memory cell axis of length self.constant_memory_cells. So in the case of, say, 202 memory cell AGIPD operation, slicing a constant with 352 cells down to 202 is no problem. What do we do if one day we get constants smaller than expected? Right now, any frame outside bounds of constants is just not corrected at all and that seems the most reasonable solution, so I'd be hesitant to ad-hoc create smaller buffers for individual small constants. Or should we employ something like this to ensure that we always have enough correction constant cells? 🤔

Merge request reports