[Jungfrau][Correct] Account for missing fixed gain constants when burst mode in dynamic gain
Description
MID started recorrecting data from October in burst mode. These data were corrected before with dynamic gain constants and no fixed dark constants were taken.
This MR accounts for this by expanding https://git.xfel.eu/calibration/planning/-/issues/196 to force fixed gain constants for burst mode in dynamic gain. Then in case of no available constants check for dynamic gain constants. These constants will be accepted only if they don't have more than 3-day time difference with the RAW data.
- New functions: jungfrau_cal_mdata and force_fixed_gain_constants
- Try retrieving fixed gain constants, try retrieving dynamic gain constants if no fixed constants
- Dont accept dynamic gain constants older than 3 days
How Has This Been Tested?
-
TBD
Relevant Documents (optional)


Types of changes
- New feature (non-breaking change which adds functionality)
Checklist:
Reviewers
Merge request reports
Activity
added Testing label
assigned to @ahmedk
- Resolved by Karim Ahmed
Thanks! I was actually thinking of erroring out initially, but after second thought, a warning is sufficient. If there's an incident about data quality, the warning will be helpful.
changed milestone to %3.11.5
added Waiting for review label and removed Testing label
- Resolved by Karim Ahmed
" if abs(time_difference.days) > 3:\n", " warning(\n", " f\"No dynamic gain constant retrieved for {mod} with at least\"\n", " \" 3 days time difference with the RAW data creation date.\"\n", " \" Please make sure there are available constants.\")\n", " jf_metadata[mod].pop(\"Offset10Hz\")\n",
Originally I envisioned we would raise an exception in this case. But having a warning seems a reasonable, and sufficiently document what happened in case it becomes an incident.
274 322 "\n", 275 323 "# load constants arrays after storing fragment YAML file\n", 276 324 "# and validating constants availability.\n", 277 "const_data = jf_cal.ndarray_map(metadata=jf_metadata)" 325 "const_data = jf_cal.ndarray_map(metadata=jf_metadata)\n", 326 "\n", 327 "# For plotting\n", 328 "da_to_pdu = {}\n", 329 "for mod_info in jf_cal.physical_detector_units.values():\n", 330 " da_to_pdu[mod_info[\"karabo_da\"]] = mod_info[\"physical_name\"]" The
CalibrationData
API (v2) could probably provide something like that. Especially with trying to make aggregators less prominent, such a mapping seems useful.(More a train of thought, ont meant as MR comment)
Edited by Philipp Schmidt
mentioned in commit dee3590a