Minutes of the Testbeam Meeting, held Thursday, February 27, 2003
 =================================================================

 (Present:  ML, NK, TI, MF, TS)

 - Margret mentioned that she is working on untangling the
   longitudinal information of the EMEC to find out where the
   boundaries of the depth segments are. It will help
   to know this for analyzing the combined testbeam data.


 - Michel pointed out the benefits of a "geometry service":

   In Athena it is possible to obtain eta, phi, deta and dphi
   for the geometrical centre of a cell. There are benefits
   of knowing the 3 dimensional information of a cell in Atlas,
   and a geometry service should be written that translates between
   the different possible geometries - design geometry, testbeam
   and translated cryostat in Atlas.
   This geometry service should be written now.
   It will be helpful for work with jet clustering in Atlas.
   What we need are coordinates of the front face, back face and
   somewhere in the middle.
   We have to think about what we need.
   Possible scenarios would be:
   For each channel number: give two values each for eta, phi and z.
                        or: give x,y,z of a 3D centre
                        or: give x and r and a point at some %-age in depth
                            ...
   This would be useful for testbeam. For Atlas we might need
   something else, like for each channel number:
                     give: eta', phi', z' of a 3D centre
                       or: eta', phi' of a point at some %-age in depth
                       or: eta1, eta2, phi1, phi2, z1, z2
                       or: x, y, z

   This code can be written right away, even without knowing the
   numbers that will have to go into it.
   Once the numbers are ready one can get x,y,z for the testbeam.

   Another serrvice that can be written is any line under any angle
   in 3D - which cells does it go through? This will be useful
   for muon analysis and em shower analysis.

   Or a service that has a cylinder in x/y (instead of a line).
   Or one, where given a circle with radius r and position x, y,
           where does it project through through?

   What we need is to find out what we want, but we should do that now.
   We need to find out which cells to include in a cluster.
   We can then determine the width of the shower and study the width
   of the shower as a function of energy. In the EMEC, that can be
   more complicated than in the HEC.
   We should check whether Services of this kind already exist.

   For the testbeam we have to figure out the geometry unambiguously
   in the coordinate system of the testbeam setup.
   It would be nice to have a Service in TBRootAna to convert between
   different coordinate systems.

   In the HEC, the printed circuit boards define the segmentation
   in depth. There are 7 types of different (ganged) boards.
   For a centroid - which number of the coordinate system should be used?
   There are 32 lines in r: r1, r2, z1, z2, phi1, phi2 in some
   local coordinate system - but  that is also not pointing.
   It is not neccessarily clear ho to define a cell in eg. LSEG2.

   One should make a approximation and say it is "pointing". Once we
   assume it is pointing, 6 numbers are needed to define the boundaries
   and then one can have a service to get the Atlas coordinates or the
   testbeam coordinates.


   And, as a final note: we should think about what first steps we want
   to take, which analysis to approach and have a global picture in mind!