Page History

...

Before it is associated into a calibration collection, however, we still need a way to uniquely identify a master calibration, at the very least so we can later identify which dataset we're associating with each validity range.  In Gen2, we used a calibDate  field for this, which no one was happy with, and that's what the calibration_label  was intended to play replace (with the content of that label still very much TBD; it could also be date based, or computed from the constituent visits, or a counter...): the full data ID for a bias would be instrument+detector+calibration_label .  We With calibration_label no longer needed for validity ranges, we now have two ways to proceed:

• We could continue to use calibration_label  as part of the data IDs for master calibrations (and possibly rename it to reflect how we expect to populate it, once that's decided).  This would allow us to have multiple calibrations of the same time type and "rest of the data ID" in the same run (i.e. multiple master biases for the same instrument+detector , which would eventually be mapped to different validity ranges), which would be most natural if we expected to produce them at once (i.e. in a single QuantumGraph execution).  But we would have to add logic to the lookup within calibration collections to not require the calibration_label  part of the data ID there, because it would be redundant with the validity range lookup.
• We could drop calibration_label  entirely, and put master calibrations that would otherwise conflict in different runs as they are created, so (e.g.) within any run an instrument+detector lookup for bias would be fully qualified.  This would be the most natural approach if we really do only want to produce master calibrations one-set-at-a-time with explicit validation before blessing them (which is here expressed as assocation with calibration collection), and it saves us from having to cook up something to put in the calibration_label  string.  But as all other QuantumGraph execution puts all outputs datasets into a single run, we would either need to add more special-casing or levels of indirection to that higher-level code or rule out any single-QuantumGraph method of producing conflicting master calibrations.  (To be clear, this would be a prohibition on e.g producing multiple biases for the same detector in a single QG; there would not be any prohibition on producing a single master bias for each detector in one QG).

...