Overview for generating EEMC pedestals and status tables

This is an informal overview of the 'philosophy' used to generate pedestals and status tables for the STAR endcap EMC, and in particular the ESMD.

For the EEMC offline database, the default protocol is to store one set of pedestals and status tables per fill for the pp runs. In general, this information is updated less frequently for heavy-ion running, depending on user demand.  For the endcap, other database information, such as detector mapping and gains, will apply for much longer timescales (like years, or at least a whole run), and so there may be a single database entry for an entire running period.

Focusing on the smd strips, our guiding assumptions are pretty simplistic: First, strips that have constant problems (i.e., those that stay bad after their crate is reconfigured or power-cycled, for example) are easy to catch, and will be flagged as bad no matter what data are used for QA. These aren't the concern. The messier case is when channels suddenly go bad, but can be recovered later (by power-cycling, etc.).  We assume that these sorts of problems, which tend to affect an entire FEE card and not individual channels, can occur at any time while running, but especially at the very start of a fill during tuning and collimation of the beams. These problems don't often fix themselves, and so will remain until action is taken - which usually occurs only between fills.

For the smd strip pedestals and status tables, we analyze one min-bias run per fill, preferably one taken near the end of the fill. Guided by the above ideas, we assume that by this time we have 'accumulated' all the problems that will arise during the fill, and we will mark them as bad for the entire fill. This means that any strip that died or developed some problem _during_ the fill is marked as bad even for the runs early in the fill when it was still working. So it is a conservative approach: If a strip was malfunctioning near the end of the fill, we assume it was bad for the entire fill.  It is clear that if such problems are only cured in-between fills, this all makes sense.  If a problem is truly intermittent, however, and comes and goes from run to run, then in this approach we might catch it, or we could easily miss it.

Updating the status information in the database on shorter timescales, or basing each entry on more than one run per fill (e.g., take an OR of problems found at the start and at the end of each fill), is certainly possible - it just requires more time and effort.  At this point, we don't plan to change our protocol unless new and unexpected time dependences are observed for problems that don't fit into our model of channels breaking and being 'fixed.'   I don't think our current assumptions are totally screwy.  Just from watching the P-plots, one can see that the endcap smd spectra start to get 'ratty' after a few fills, as more and more groups of four strips (which are consecutive in DAQ and P-plots, but not in the physical detector) start to drift around in their pedestal, or go south in some other manner.  After a thorough re-cycling, most of these problems can be fixed, so things look pretty good again at the start of the next fill.

Nevertheless, at the end of the day, the most relevant question for the endcap status tables is "are we doing well enough?" and the best feedback comes from doing real analysis.  So the more that people stare at spectra and find new problems, especially those with unexpected time dependences, the better we can design our QA algorithms and protocol to identify and keep track of them.  No matter what sorts of problems we have found in the past or might have anticipated, nature always finds new ones, and we rely on users to point these out.