EMCAL DB Use Cases

Intent of this document

Content

• Offline calibration (DST production)
• EmCal-FEM configuration handling (to be done)
• Pedestal measurement, and subtraction (i.e. pedestal-DB writing/reading) (to be done)
• High/Low gain combination (to be done)
• Amplitude linearity correction (to be done)
• Gain determination (to be done)

Please voice if we miss some or if we split them too much or not enough...

When preparing this document, we intended to go through all these use cases. But we soon realized that we lack some depth in the understanding of many problems involved. So we have or will asked questions about that to people who know... Also, all use cases need not to be done by us. If you know how to do something, please document it yourself for the benefit of all EmCal !

Use Case

Typical use case for the offine is the DST production : raw data needs to go from ADC counts to GeV and ns.

In this simple use case, we already see two different kinds of DB "data" :

Calibration data

Ideally, this should be, for each tower, a set of four numbers a,b,c,d, so we can then calibrate a tower as : E(GeV) = a.E + b and T(ns) = c.T + d.
The computation of a,b,c,d may require to access specific part(s) of the DB, depending on how we organize things, but there should be a way of asking for a,b,c,d directly, without knowing from where they come.

Configuration data

This is at least the EMCAL-FEM combination (i.e. which FEM were connected, and to which EMCAL supermodules), so that offline is only given the active channels.

We miss something in the above use case, namely the DB entry points. For the calibration data, we for sure use the tower (absolute) number, but we also need the event number+run number+time (e.g.PHBigTimeStamp) as a way to access the DB.

Class Diagram

A class diagram corresponding to the above use case could be like that :

In the above design, we can choose between different calibration strategies, possibly at runtime (if we use a Factory to create CalibrationStrategy objects for instance). For example, in the emcCalibTower module, the code could be :

static emcCalibrationStrategy* calib = 
             emcCalibrationStrategyFactory::GetInstance()->
             CreateCalibrationStrategy("name_of_strategy") ;

for ( i=0; i < dEmcRawData_h->nok; i++ ) {
  e_lo = calib->Calibrate(event,
                dEmcRawData[i].swkey,
                dEmcRawData[i].adclopost-dEmcRawData[i].adclopre,
                dEmcRawData[i].tdc,
                dEmcCalibTower[i].ecal,
                dEmcCalibTower[i].tof) ;
  ...
}

Please note that using such a generic interface (emcCalibrationStrategy) and factory (emcCalibrationStrategyFactory), the offline code would not have to be recompiled every time we change something in the calibration classes. Note also that a calibration strategy need not to access the DB, if it's not wanted...

A note about DB Access

The emcDatabaseAccessor in the above diagram would be a Singleton (global class) which responsabilities cover ALL accesses to the Emcal Database.
[ This class does not have to actually do all the work by itself. There's a nice Design Pattern called Facade which could be used to provide a unique interface (through emcDatabaseAccessor interface) from a bunch of related classes. ]

Also, this class must be accessible from all Emcal processes (being online or offline), that's for sure. A slightly different question is "do we need the object of this class being accessible from all Emcal processes ?". If we would like to do so, we should consider the following points :

• We must choose the InterProcess Communication technology (this is a more general issue than just DB, see Sergei Belikov mails about IPC on emcal-l) : CORBA, ROOT TCP/IP, home-made TCP/IP ?
• We should separate the problems : let's define the DB access (goal #1), let's define some Emcal IPC mechanims (goal #2), and then let's try to mix them if we need so (goal #3).
• We should use the Proxy Pattern to make this transparent to the user processes.
• If all Emcal processes access a single emcDatabaseAccessor, would not this object become an ugly software bottleneck ?

Conclusion

The DST production does not access directly the emcDatabaseAccessor object. It only talks with one of possibly many Calibration Strategy objects. At this point of the problem analysis, the DB Accessor class should provide methods to :

• get pedestal value for one given tower at one given (time/run/event)
• get gain value for one given tower at one given (time/run/event)

We now turn to the DB structure/content. Pedestals handling is well separated from all other stuff, so I think it make sense to have a separate database (in the Objectivity vocabulary) for them. As other steps in the calibration need those pedestals, we should probably focus on this database (and the corresponding user interface) first (once we have understood what those pedestal matrices are all about, of course...).

... to be continued ...