Online calibration needs questionnaire

Over the past month, we have been working toward defining the support for calibrations in the BABAR online system. Our initial work was based on the requirements of the DIRC system, with some attention to the drift chamber and calorimeter.

We have now developed a working model, but before we can proceed with it we now need determine whether it will in fact work for the foreseeable calibration needs of all the subsystems. David Brown has presented the working model at the October 1996 online review and will present it at a calibration parallel session during the October collaboration meeting.

The purpose of the questions in this note is to elucidate the various needs of the detector subsystems for online calibrations and to understand whether and how these can be supported in our present model, as well as to begin the process of planning all our calibration activities to fit within the constraints of efficient factory running.

Brief summary of the model

This note largely relies on the assumption that readers have seen one of David Brown's presentations on the calibration model in October 1996 or have otherwise heard or read about it through David, Gregory, or other online people.

A very brief summary of terminology:

Pulse

This is the (tentative) name chosen for the basic unit from which most calibrations will be constructed: a calibration strobe (CalStrobe) signal followed by a Level 1 Accept (L1Accept) signal^[1].

Minor cycle

A minor cycle is a series of pulses. Subsystem discussions to date have indicated needs for anywhere from ten to 100,000 pulses per minor cycle. For most cases, the Fast Control Partition Master (FCPM) would be set up to generate the required number of pulses using a programmable hardware counter, but minor cycles could also be run entirely under program control.

Generally the function of a minor cycle would be to collect statistics on the response to a single set of calibration stimuli (e.g., DAC settings).

Major cycle

A series of minor cycles. Generally the calibration stimuli might be changed for each minor cycle, for example to trace out a pulse-height-to-counts relationship, but the minor cycles would be otherwise similar to each other. Major cycles may contain any number of minor cycles, including one (e.g., for a pedestal measurement).

Meta cycle

A series of major cycles. Generally the major cycles might be all different from each other; a meta cycle is intended to encapsulate the extraction of a complete, useful set of calibration information. An example of a meta cycle, for the DIRC, might be {pedestals, gain, efficiency, T-zero}, where each of the four steps would be implemented as a major cycle.

Pulse data will show up first in the ROM. At each level of the above hierarchy, it will be possible to decide whether to retain the data in the ROM for further processing or forward it on through the Dataflow system to the OEP system for processing in a Unix environment. This system thereby supports scenarios ranging from what we call "Slow Calibration", in which every pulse's data is read out as an event, and analyzed in the OEP/Unix environment, through a refined "Fast Calibration" in which all the calculations and determination of a set of constants for a system is done entirely in the ROMs, taking advantage of the intrinsic channel-by-channel parallelism of typical calibrations.

Basic calibration needs

Answers to the questions below would be very useful in defining both the capabilities of the online system for calibration and for planning the calibration schedule in view of our requirements for high efficiency running.

How many channels of electronics does the subsystem have?

(Include whether there are multiple channels per detector element - e.g., the TDC and ADC on drift chamber wires.)

What quantities are needed per channel, and at coarser granularities, for online sparsification, data correction, feature extraction, triggering, and reconstruction purposes?

(Examples: thresholds, pedestals, counts-to-time and counts-to-PH relationships, dead/hot channel maps.)

How well do these quantities need to be known?

How often and under what circumstances are these quantities expected to change by amounts comparable to their precision?

What machine precision and format are expected to be required to represent these quantities (i.e., how many bits, integer vs. floating point)?

[The answers above should allow estimates of the overall size and accumulation rate of constants for the system. These are important for deciding on the basic hardware requirements of the online system for storage and throughput.]

Under what circumstances will these quantities be determined?

(Possible options: derived from physics data, from dedicated calibration runs, or from calibration events interspersed with physics data during running.)

For the latter two options, what will be the nature of the calibration stimuli?

(Examples: electronics calibration with signal injection, light pulsers, radioactive sources.)

Frequency of calibrations

Based on discussions with detector systems to date, and on Vera Lüth and Jonathan Dorfan's remarks on the deadtime budget, we have drafted an indicative table of possible categories of online calibrations.

Do the calibrations envisioned for this subsystem fit into this table?

(Please describe your vision of the sorts of calibrations that will be needed during normal running for this detector subsystem.)

[The goals here are to determine what is needed by the subsystems but also to begin to apply the stringent "factory running" deadtime budget constraints to these needs. This will be the beginning of a long process.]

(It is recognized that during commissioning and debugging there may be additional types of calibration runs needed that may not fit into this structure quite as well.)

Operational details

What are the physical sources of the calibration stimuli? Especially, how many are they and how are they distributed?

(Examples: one per channel, one per front-end element, one per ROM, one per crate, several for the system but not aligned on crate or module boundaries, one for the entire system?)

How are they controlled?

(Examples: through front end protocol, special module in DAQ crate, non-DAQ crate under Detector Control.)

[The answers to the last few questions are of particular importance in ensuring that the online system has all the tools necessary to run detector systems through complete calibrations, including the setting of conditions for calibration stimuli.]

Fitting into the model

Do the calibration procedures envisioned for this detector system appear to be able to be fit into the pulse/minor/major/meta cycle model of calibrations mentioned above (and described in more detail elsewhere)?

If no... what's missing?

If yes...

Details

For now, we consider only "fast calibration" scenarios, in which data from individual pulses need not be retained, and channel-to-channel correlations across ROM boundaries need not be made. If these considerations are not met, we are in the "slow calibration" regime, which is more analogous to normal data-taking.

Please consider these questions for each type of calibration envisioned. Multiple answers to each question may be appropriate.

For each type of calibration, how many pulses will be needed in a minor cycle?

(Examples from information already accumulated: 10-20 pulses per minor cycle in tracing out a calorimeter PH-to-counts relationship, 1000 pulses to provide a 10% measurement of DIRC efficiency, 100,000 pulses to provide a 1% measurement.)

What are the detector system's internal limits, if any, on the rate at which a minor cycle can run?

(Example: a flash tube which can only run at up to 100 Hz.)

How many minor cycles are needed in the major cycles?

What changes in calibration stimuli are envisioned to be needed between minor cycles?

What is the setup/settling time expected for these changes?

Conditions changes requiring going outside the DAQ system to set up, for instance to Detector Control, will expand the boundaries of the facilities the online calibration system need to provide. This may be of particular concern if such changes need to occur within a major cycle. We'd like to know what the occasions for such changes might be.

What information will be collected during a minor cycle?

(I.e., statistics, histograms, etc.)

What is the volume of data involved per channel?

(Example: one histogram of 50 bins with 16-bit integer counts.)

How long does this information need to be stored for reference and archival purposes?

(Example: all histograms from all calibrations of this system over the most recent two weeks, with one set of histograms per week preserved indefinitely.)

What processing needs to be performed on that information at the end of a minor cycle?

(What's of particular interest here is whether the processing is self-contained, at least at the ROM level, or whether it might need to cross ROM boundaries or access databases in data-dependent ways.)

(It would also be interesting to know whether the processing can all be performed using deterministic-time algorithms; this is of some importance in considering reliability of code in the ROMs.)

What is the result of this processing? How large is it, and how long does it need to be retained?

(The set of such results would then typically make up the data for an entire major cycle.)

What processing needs to be performed at the end of a major cycle?

What is the result of this processing? How large is it, and how long does it need to be retained?

What changes in calibration stimuli are envisioned to be needed between major cycles?

What additional processing, if any, is expected to be needed at the end of the meta cycle(s) envisioned for this subsystem?

(The results of the major cycles themselves may be sets of calibration constants, and the meta cycles nothing but collections, but there might also be significant processing at the meta cycle level.)

What mechanisms are needed for determining the correctness and usefulness of calibration constants determined by these procedures?

(Examples: comparison with standard values, evaluation of changes from previous calibration.)

Can the procedure of "blessing" constants as acceptable for use in data-taking be automated?

Are these constants required to be fed back into the online, with an influence on data-taking?

For this subsystem, would a "leap-frog" scheme be acceptable for this?

(Given the series {..., Physics-run-1, Calibration-run-2, P-2, C-3, P-3, ...} would it be acceptable to start P-2 immediately after C-2, verify the correctness of the constants calculated from C-2 during P-2, and then only apply those constants during P-3? This scheme would eliminate the time required to calculate and verify constants from the deadtime budget. If the C-2 constants were found to be wrong in such a way as to indicate a detector problem, of course, P-2 could be aborted.)

Performance

In order to meet the subsystem's goals for the duration of calibrations, what data acquisition rates within minor cycles are desirable? Required?

^[1] The term "pulse" is largely a notational convenience adopted to provide a name for the elements from which a "minor cycle" is constructed. What really matters to the online is the Level 1 Accept itself. The Fast Control Partition Master (FCPM) has the capability to generate more complex sequences than the "N x (CalStrobe,L1Accept)" considered here. A sequence can be made up of a variable number of repetitions of a group of up to three front-end protocol commands, with adjustable delays between them. The usual pattern will be the simple "CalStrobe, L1Accept". However, "CalStrobe, CalStrobe, L1Accept" is also a possibility, and more interestingly "CalStrobe, L1Accept, L1Accept". Deciding whether to think of the latter as one or two "pulses" would probably just confuse matters. (The CS,L1A,L1A pattern could be used for a signal, pedestal, signal, pedestal, ... sort of test.)