Online Calibration Needs Questionnaire

Identity of respondent

Name:
E-mail address: (this address will be used for correspondence in reply to your posting)

Subsystem: SVT Drift Chamber DIRC Calorimeter IFR Trigger Other: 

Is this response advisory, or an authoritative subsystem submission?

Is this a new response, or a continuation of or addition or correction to an earlier response from the same author on this form?

Basic Parameters of the Subsystem

• Number of independently read out channels of electronics in the subsystem: .

• Please give a precise definition of what constitutes a "channel" for the purposes of the previous answer. (Describe the physical detector elements involved, what sorts of measurements are acquired from them, etc.. If a single physical element is read out in multiple ways - e.g., both a time and a pulse height from a single PMT - please include this in your answer.)
  

• How many channels will be read out through each readout section ("front end section") in the subsystem?
  

• What is the expected structure of the assignment of readout sections to ROMs? You may wish to include information on how physical segmentation of the subsystem maps into the distribution of channels and sections among the subsystem's ROMs. (Example: the mapping of DIRC sectors onto ROMs.)
  

Calibration Types and Basic Characteristics

This questionnaire is concerned with online calibrations, meaning those either determined or used anywhere in the online system before Prompt Reconstruction. Most importantly, it addresses those calibrations obtained by providing the system with controlled inputs ("electronics calibrations" and "pulser calibrations"). Nonetheless, any calibration, however performed, which results in data that must be fed back into the online system, especially into the front ends, ROMs, or ROCs, is of interest at least in the initial sections of this form.

• A variety of processing steps are performed in the DAQ and online systems on acquired data, including, loosely, the application of thresholds in hardware, further sparsification in subsequent downstream stages of the system, data correction, feature extraction, triggering (Level 1 and Level 3), and reconstruction.

  It is difficult to devise a structured set of questions to explore the subsystems' needs in this regard, but we are looking for quite detailed answers to the following rather general and vague question, characterizing the full set of types of calibrations needed by each subsystem.

  What sets of quantities are needed per channel (or potentially at coarser granularities, for online sparsification, data correction, feature extraction, triggering (including Level 3), and reconstruction purposes, and how will the information be used? Please give each type of of information a distinctive name, and then use this name, which will be referred to as a "calibration type", consistently throughout this document. (Examples: thresholds, pedestals, counts-to-time and counts-to-PH relationships, dead/hot channel maps.)
  

Please answer the following questions for each calibration type described in the previous answer. Note that you may submit multiple copies of this form, perhaps one per calibration type, if you would like to avoid combining your answers and reduce crowding in the form. Please check the "continuation" box in the "Identity of Respondent" section above for responses after the first one.

• Where in the system will the quantities from each calibration type be used? (E.g., in the front ends, in the readout modules, in the Level 3 trigger algorithms, etc.)
  

• How well do these quantities need to be known? Specifically, how closely must they approximate their "true" or ideal values in order not to make a significant contribution to the resolution obtained by the subsystem on physics quantities? (Example: pedestals on a pulse height measurement might need to be known to 1%, or times to 1.5ns.)
  

• How often and under what circumstances are the quantities for each calibration type expected to change on the scale of the above described accuracy? NB: This question is not "how often will the system need calibration?", which appears later in the questionnaire. (Examples of "circumstances": ambient pressure changes, new PEP-II fills, detector shutdowns, magnet crashes, or just the passage of time.)
  

• For each channel and calibration type, how many numbers of what machine precision and format are expected to be required to represent the calibration ("format" = e.g., integer or floating point, "machine precision" = number of bits)?
  

[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 and software requirements of the online system for storage and throughput.]

Sources of calibrations and required conditions

Again, please answer the following questions for each calibration type described above.

• What will the sources of data for the determination of the constants described above be? (Examples: derived from dedicated calibration runs, from physics data, from calibration events interspersed with physics data during running, etc..)
  

• For calibrations based on data acquired during normal running, what types and volumes of data will be required? (Examples: "10000 dimuon events", "at least 25 Hz of Bhabhas", "multi-prong hadronic B events"...)
  

Most of the questions from here on are applicable primarily or exclusively only to those calibrations performed in the online system.

• For calibrations not obtaining their data just from normal physics running, what will be the nature of the calibration stimuli? (Examples: electronics calibration with signal injection, light pulsers, radioactive sources.)
  

• What, specifically, will be the actual physical sources of the above stimuli? How many such sources will there be in your system, and how will they be distributed? (Examples: one per channel, one per front end section, one per ROM, one per crate, several for the system but not aligned on crate or module boundaries, one for the entire system?)
  
• How will these sources be controllable? (Examples: through the front end protocol, a special module in a DAQ crate, a non-DAQ crate under Detector Control, or by a person having to turn a physical knob.)
  

[The answers to the last two 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.]

• What detector conditions will be required for each calibration type? (Examples: solenoid on/off, high voltages on/safe/off, gas on/off.) Please consider not only your own subsystem's conditions, but also another others' which might affect your calibrations. (Hypothetical: one subsystem's cooling system being on or off, or its power supplies being on or off, might affect the thermal environment for another. This part of the question may be very difficult to answer before we are actually running.)
  

• What PEP-II machine conditions will be required for each calibration type? Specifically: 1) are stable colliding beams acceptable? 2) is the calibration possible during injection? 3) if beams interfere with calibration, could it be run during the ion-clearing gaps in the stored bunch trains? 4) what, if any, calibrations must be done only with the beam off? 5) if the beam is off, can the state of the PEP-II magnets near the detector or the RF system affect the calibration?
  

Partitionability

• If your subsystem has more than one readout crate, do you expect to be able to partition the subsystem and run different calibrations on different crates, run a calibration in some crates while collecting data in others, etc.? Can this be done with arbitrary subsets of the subsystem's crates? Are the calibration stimulus sources partitionable by crate, or are there individual sources which can affect more than one crate at a time? (Hypothetical example: the light pulser for the EMC might be controllable separately for the barrel and the endcap, but not allow independent pulsing of readout crates within the barrel.)
  

• What other subsystems' calibrations might be expected to create unacceptable interference to your system's? Please explain the nature of the conjectured interference. In a partitioned detector, could any other subsystems' normal data-taking create interference with your calibration?
  

• To which other subsystems' calibrations might your system's calibrations cause unacceptable interference? Please explain the nature of the conjectured interference. In a partitioned detector, could your calibration create interference with any other subsystems' normal data-taking?
  

• Is this subsystem anticipated to need any calibrations which would require running together with another subsystem? (Hypothetical example: a trigger analog test which would require running the trigger in the same partition as the EMC and/or the drift chamber.)
  

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 list of categories of online calibrations in the factory environment.

Frequency	Duration	Maximum # of Pulses	Schematic purpose
?	non-intrusive	~10-100	Continuous monitoring
~1/hour (at top-off)	< 1 min.	~10^3	"System operating OK" checks (~30% window), pedestals, verification of existing calibrations
~1/shift to 1/day	< 5 min.	~10^4 - 10^5	Precision constants for production running
~1/week to 1/month	< 1 hour	~10^7	High precision stability and crosstalk tests, slowly-varying constants

The duration limits apply to loss of otherwise useful machine time - i.e., not including PEP-II down time. The limits also assume that calibrations of different systems will indeed happen in parallel, or at least that the duration is in fact the total available for all subsystems.

• Do all the calibrations you are envisioning fit reasonably into this structure (or have even less stringent requirements)? Yes No

• To the extent that they do, please describe how. If they do not, please explain in detail the requirements of your subsystem that cause your calibration needs to exceed the constraints of the above outline.
  

[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.

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

Fitting into the Proposed Calibration Environment

The questions in this section refer to the basic pulse/minor cycle/major cycle/meta cycle model of calibrations in BABAR presented in the overview associated with this questionnaire, and, in greater detail, at various recent collaboration meetings and reviews.

This model probably does not apply to calibrations obtaining their inputs from normal physics data-taking, even if they are performed within the online system. The remainder of this form probably is of little relevance to such calibrations; further information about them will be solicited from subsystems separately, at a later date.

• Do the calibration procedures envisioned for your detector system appear to be able to be fit into this model? Yes No
  • If not, please explain. What operations do your calibrations require that can't be accommodated in this scheme?
    
  • If yes...

Details

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

Pulses

In the basic model, a "pulse" consists of a "CalStrobe" command (in the sense of the front end protocol) followed by an "L1Accept" command. Within a minor cycle, there will be a programmable interval from "CalStrobe" to "L1Accept" of no less than 2.2 microseconds (the minimum inter-command spacing), and then another programmable interval from the "L1Accept" to the "CalStrobe" of the next pulse. The sum of the two delays will therefore set the pulse rate.

Despite the single CalStrobe per pulse, multi-hit calibrations can be accommodated in this system if a subsystem's electronics can generate more than one stimulus on a single CalStrobe.

Calibration stimuli not able to be triggered by a CalStrobe command can be accommodated if the calibration source itself can generate a trigger.

• For each calibration type, please state which of the two models above, "pulse = (CalStrobe, L1Accept)" or "pulse = external trigger from stimulus generator" will be used. If neither of these is acceptable, please explain this in detail.
  

• Is the minimum 2.2 microsecond CalStrobe-to-L1Accept delay acceptable? (This is a hard limitation in the basic design of the DAQ system. It should cause no problems with calibration, but if it does, it is essential that we know this immediately.) Yes No
  If not, please provide a detailed explanation:
  

• The CalStrobe-to-L1Accept delay is programmable to values larger than 2.2 microseconds. Will this be required for your calibrations? Will it be necessary for the delay to be changed during a single calibration?
  

• What processing will need to be performed on the data from each pulse? (Examples: increment a counter, accumulate a set of one-dimensional statistics, fill a histogram.) Knowing the computational load, especially at the per-pulse level, will be important in evaluating the achievable performance of calibrations. Although it will likely be difficult for subsystems to give quantitative answers to this question immediately, they will be needed before long and it would be good if subsystems began working on developing numerical estimates for CPU time required for calibration processing.
  

Minor Cycles

A minor cycle is defined as a series of pulses taken under constant conditions. Normally this would be to accumulate statistics on data taken with, for example, a particular DAC setting. In the model, the number of pulses in a minor cycle must be set in advance.

• For each calibration type, how many pulses will be needed in a minor cycle? (Examples from previous discussions with subsystems: 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.)
  

• Can the calibration tolerate deadtime? Deadtime is presumably undesirable, since the affected pulses are basically wasted. However, if the system is being operated near its performance limits, deadtime can arise, and so it is important to know whether deadtime will merely cause a loss of statistics in the calibration or whether it might be disruptive in some other way to the data collected.
  

• What are the detector system's internal limits, if any, on the pulse rate at which a minor cycle can run? These could be limits in the calibration stimulus source (e.g., a flash tube which can only run at up to 100 Hz), or in the physical response of the detector or electronics (e.g., pileup problems). Excluding the general consideration of completing calibrations as fast as possible, is there an optimal rate on physical grounds?
  

• What information will be collected during a minor cycle (e.g., statistics, histograms, etc.)?
  

• What will be the volume of data involved per channel? (Example: one histogram of 50 bins with 16-bit integer counts.)
  

• What processing will need to be performed on that information at the end of a minor cycle? (Examples: calculate one-dimensional statistics, fit a histogram.) Will the processing be independent for each channel, or will it be necessary to combine data from multiple channels? (Of particular interest here is whether the processing will be self-contained at least at the ROM level, or whether it might need to cross ROM boundaries or access databases in data-dependent ways during the calibration. It would also be interesting to know whether the processing can all be performed using deterministic-time algorithms; this is of importance in considering reliability of code to be run in the ROMs.)
  

  Again, although we recognize that this will be difficult for subsystems to provide immediately, CPU time estimates for this processing would be quite useful to our planning.

• What will be the result of this processing? How large will it be per channel? (Note that this need not be the same as the volume of data collected during the minor cycle.)
  

• How long will this information need to be stored after a calibration is complete 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.)
  

Major Cycles

Major cycles will be series of minor cycles, with a provision for changing the calibration stimulus or other conditions before each minor cycle begins. Possible major cycles might be one consisting of a single minor cycle, in order to measure pedestals, or one consisting of a series of minor cycles each accumulating data at a single point on a pulse-height-to-digital curve. The result of a major cycle would thus typically be a traditional set of calibration constants, e.g. pedestals or gain curves.

• How many minor cycles will be needed in the major cycles?
  

• What changes in calibration stimuli are envisioned to be needed between minor cycles? (Examples: change DAC value, adjust calibration signal timing.)
  

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

• How will these changes be controlled? 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 will 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 and to try to avoid them.
  

• What processing will need to be performed at the end of a major cycle? Similar considerations apply as in the case of the minor cycle question above.
  

• What will be the result of this processing? How large will it be per channel? This result may be the "calibration constants" themselves. Please indicate whether this is likely to be the case or whether further processing will be needed. It is assumed that in all cases there will be an additional "calibration validation" stage of processing; this is addressed below.
  

• Longevity of final calibration constants is addressed in a further section below. To the extent that the major cycle result is not yet a set of such final constants, how long will this information need to be stored after a calibration is complete for reference and archival purposes?
  

Meta Cycles

A meta cycle is a set of major cycles. It is the largest unit of calibration. When a user at an operations console requests a calibration during normal operation, the request would typically be for a particular type of meta cycle to be executed.

Meta cycles could take many forms. The simplest meta cycle might be something like "run pedestals", consisting of a single "pedestals" major cycle which in turn consisted of a single minor cycle. One could be nothing more than a collection of several major cycles, each producing an independent set of calibration constants, but needing to be run together in order to fully calibrate a subsystem, whereas another might have significant summary processing at its end, combining the results of all its major cycles.

• In the light of the previous paragraph, what sorts of meta cycles do you envision for your system?
  

  Specifically,

• What changes in calibration stimuli or other subsystem control parameters are envisioned to be needed between the major cycles within these meta cycles?
  

• What additional processing, if any, is expected to be needed at the end of the meta cycles envisioned? Or, is the collection of the results of the major cycles itself the result of the meta cycle without need for further processing?
  

• Within a meta cycle, may major cycles following the first one proceed before the results from the previous major cycle have been validated (see below)? (In other words, may major cycles be pipelined?) The answer to this question might well be different for every meta cycle, and it may be difficult to answer at this time. Please try to consider, though, which of the major cycles you are envisioning might depend on validated results from a previous one.
  

Validation and Verification

It is assumed that no set of calibration constants will be put into production without its validity being tested in some way. These tests might include checks of histogram fit qualities, comparison of constants to earlier sets or reference sets, and so on.

It is also envisioned that not every measured set of calibration constants, even if passing these tests, would be put into production (e.g., in the data correction and feature extraction algorithms in the ROMs). There may be a value placed on retaining a single set of calibration constants in production for as long as newer sets are not found to deviate from it by more than a specified tolerance.

The term "validation" will be used to describe the process of determining that a just-measured set of calibration constants is accurate and error-free within specified limits. The term "verification" will be used to describe using the results of a recent calibration run to determine whether or not the existing production constants are still usable.

Verification may be desired to be performed using sets of constants, say, of lower statistical precision than would be acceptable in production, as they might still give an indication of whether a dramatic change had occurred in the system which could require the determination of a new set of precision constants for production. This could provide a sort of cheap insurance - a means of fairly frequently testing for large changes in a subsystem even when the operational constraints of "factory" running might prevent high-precision tests at that frequency.

• What mechanisms are envisioned to be needed for validation and verification, as defined above? Particularly of interest here is the distinction between tests, such as for fit quality, which can be performed on the results in isolation, and tests requiring additional input such as comparison with standard values, or evaluation of changes from a previous calibration.
  

The combination of validation and verification required to determine that a new set of constants is indeed to be put into production will be referred to here as "blessing". For successful factory running, this presumably will have to be an automated procedure.

If the constants are to be used anywhere in the online in an application that has an effect on the physics data collected (essentially, anywhere but in reconstruction), resumption of data-taking subsequent to a calibration should wait for the "blessing" and installation of new constants, if found to be required. If validation and verification turn out to be time-consuming, this could have a significant effect on operational efficiency. Therefore...

• Would a "leap-frog" scheme be acceptable for use for some or all of the constants in this subsystem? (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's data collection completed and then, during P-2, complete the calculation of the constants derived from the C-2 data, validate and, if necessary, "bless" them, and then only apply these constants during P-3? This scheme would eliminate the time required to calculate and verify constants from the overall operational deadtime budget. If the C-2 constants were found to indicate a detector problem or to seriously invalidate the previous constants, of course, P-2 could be aborted.)
  

A final performance question

• In order to meet the subsystem's goals for the duration and precision of calibrations, what pulse rates within minor cycles are desirable? Required? Please be aware that rates greater than 2kHz are in excess of the online system's already rather stringent requirements for normal physics running. While the different nature of calibration running may mean that higher rates could be achieved in certain cases, they will likely require special effort on the part of the online group in order to provide. Therefore, we would like to request that a specific quantitative justification for requirements for higher rates be provided.
  

Submit form