Access to Gaudi data : wrapped or not ?
The access to Gaudi TDS and other services requires several
lines of code, and often obfuscate the code. It can also slow
down the execution if done within a frequent loop.
One solution is to put an intermediary layer between Gaudi
and CalRecon actors. Such layer could simplify and optimize
the access to Gaudi services. History of TkrRecon has
demonstrated a strong drawback: when something goes wrong, the
intermediary level makes harder the understanding of the
flow of control, and harder the discovery of the bug.
So, we need surely a way to avoid Gaudi-like access code
within frequent loop. On the other hand, it is not
necessarily a good idea to overuse an intermediary level,
which would apprently simply code, but would make
things worse when hunting bugs.
Corrections results : generic or specific classes ?
The evaluation of event energy can be done with different
hypothesis and different algorithms. The different
class doing such energy corrections have similar
output results, and also very specific ones. The question
is : how do we define the classes which will contain
those results, and how do we collect them. We first
though about three choices :
- a single generic class, which would have two kind of
attributes : the standard attributes common to all
corrections tools, and a kind of map string->double for
the storage of the values specific to each tool
(the map could use too much space in root files, and
is hardly browsable). - a base class for common attributes, and a derived
class for each specific tool, with the specific
attributes ; all the instance being stored in a single
polymorphic collection (potentially painful to
make this persistent). - as above, but with a separate collection for each
specific class (poorly flexible, since each new tool
would require the definition of a new
specific collection).
The experience of TkrRecon says that :
- The use of inheritance and polymorphism for such data
classes is more a problem than an help. - Most of specific attributes are only valuable to specific
tools, and used for tuning and debugging. Such attributes
do not need to be necessarily stored, or their storage
can be managed privately by the specific tools.
Yet, while discussing with CalRecon contributors, it
appeared that there are some specific attributes that
we want to be stored and shared. So, the current retained
solution is :
- a single generic class, with standard attributes common
to all tools, and a map enum->double for FEW specific
attributes. - one OPTIONAL specific class for each specific tool, managed
internally by that tool.