[LPD] use memory cell order as condition for constants

Description

LPD's 512 memory cells are not necessarily filled in order - e.g. if the veto pattern is set to capture every eighth possible pulse, it might start with memory cells 8,16,24... and then loop around when it reaches the end. This filling order affects the detector's behaviour, so we want to correct the data using darks taken with the same veto pattern.

More precisely, it's OK for the cell order in the constants to be an extension of the cell order used for the data, so we're doing prefix matching. The idea is that constants will always be taken with 512 memory cells, varying only the order.

In practice, the way the veto pattern is usually set should mean the memory cell order is a function of only the first cell used and the step size, but we don't want to hardcode so many assumptions about the way the detector is configured and the way its firmware works.

How Has This Been Tested?

• @manettim has added support for string conditions to CalCat (ITDM/calibration_catalog!107), and this is running on the test instance
• I added basic support in iCalibrationDB (detectors/cal_db_interactive!86) - this pycalibration MR depends on that one.

Characterisation:

xfel-calibrate lpd DARK \
  --concurrency-par karabo_da --slurm-name dark_FXE_lpd_202201_p003073_r163_r164_r165 \
  --cal-db-interface 'tcp://max-exfl017:8015#8044' --db-output \
  --karabo-da LPD00 LPD01 LPD02 LPD03 LPD04 LPD06 LPD07 LPD08 LPD09 LPD10 LPD11 LPD12 LPD13 LPD14 LPD15 \
  --mem-cells 512 --modules 0-16 --ntrains 300 \
  --in-folder /gpfs/exfel/exp/FXE/202201/p003073/raw \
  --out-folder /gpfs/exfel/data/scratch/lpd-dark-3073-163-164-165-cellorder \
  --karabo-id FXE_DET_LPD1M-1 --operation-mode STANDARD_THREE_GAINS \
  --run-high 160 --run-med 161 --run-low 162

For correction, I needed to get a token from test_calibration and configure ~/.config/pycalibration/cal_tools/restful_config.yaml to make it talk to that instance instead of the production one. Then:

xfel-calibrate lpd CORRECT \
    --slurm-mem 700 --cal-db-timeout 300000 --cal-db-interface 'tcp://max-exfl017:8015#8025' \
    --cal-db-root /gpfs/exfel/d/cal_tst/caldb_store \
    --karabo-da LPD00 LPD01 LPD02 LPD03 LPD04 LPD05 LPD06 LPD07 LPD08 LPD09 LPD10 LPD11 LPD12 LPD13 LPD14 LPD15 \
    --bias-voltage 250.0 --capacitor 5pf --photon-energy 9.2 --category 0 --offset-corr \
    --rel-gain --ff-map --gain-amp-map --chunks-data 1 --num-workers 6 \
    --in-folder /gpfs/exfel/exp/FXE/202201/p003073/raw \
    --karabo-id FXE_DET_LPD1M-1 \
    --run 154 --out-folder /gpfs/exfel/data/scratch/kluyvert/lpd-correct-p3073-r154-vetopatt

I have checked that at least one of the constants created with the veto pattern was used for this correction.

Relevant Documents (optional)

https://in.xfel.eu/test_calibration/calibration_constants/20203#condition

LPDOffset_NoiseandDeadPixelsCharacterization.pdf

LPDOfflineCorrection.pdf

Types of changes

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.

Reviewers

@schmidtp @ahmedk @manettim