Minutes of the Testbeam Meeting, held Tuesday, December 10, 2002
 =================================================================

 (Present:  ML, NK, TI, MF)


-  Naoko gave a very nicely structured overview over the code develpment.
         (copies of her slides should soon appear on our web-page

http://particle.phys.uvic.ca/~web-atlas/atlas/hec-emec/minutes/).

         At the moment a lot of development is going on, mainly on
         the timing in LArHECTBAna (Sven and Michel).
         With at least two people in different locations seriously
         involved in the development of the same topic, there has to be a
         strategy of how to deal with the code management such that they
         can both profit from one another without getting in each others way.
             Naoko suggested that if we are using our local repository
         under the hectbmon account we can have a limited number of code
         managers. Each manager is allowed to tag his/her package and
         commit it. Naoko (manager of managers) then collects the
         different tags, makes sure that certain combinations of
         tagged packages work and provides us with a local "release".
         The user can then select which release (ie. combination of
         packages) he/she would like to use.
             This approach will only last and is only justfied as long as
         there is still extremely active development going on that
         requires rapidly changing local release tags. As soon as the code
         becomes more stable, develpoment should be done within the ATLAS
         repository. This should happen early in the new year and should
         really be our ultimate goal.

         One more comment was made on the constant data. With the
         user-spcified wac's on their way out and cell-to-cell
         timing differences being sorted out by Sven and Michel,
         we will get lots of run-number dependent constants which will
         largely be hidden from the average user, but they have to go
         somewhere. The idea is to create a new directory under
         ~hectbmon/public/tb that will hold these constant files.


- Michel reported that Sven has produced a file containg wrap-around
         constants for all run numbers (independent of trigger type)
         for this year's data.
         This development was motivated by the non-existence or whacky
         tdc information for many runs during this year's testbeam period.
         It is not clear yet whether a similar treatment can be applied to
         data of earlier years, so the idea is to have a jobOption file that
         will accomodate both approaches for now.
         With the timing becoming such an involved piece of work, it was
         suggested to create a new TDC directory for the timing.

         Pedestal files: Naoko is at present collecting them from Pavol,
         Manuella and Claudiu.

         Michel has been approached by Michael Lelchouk about Geant4 code
         for the testbeam and where such a code would end up in the
         repository. He would like to know where we would put our combined
         testbeam packages within ATLAS Athena and how to develop a
         MC repository structure for the testbeam.
         It was decided that Rob and Naoko should be in the loop for this.

         Signal shape analysis: In the peak finding, with the current
         weights the peak is only found correctly if one of the points
         used in the peak finding is actually close to the peak itself.
         If the actual peak position is somewhere half-way between two
         time samples, the peak height might not neccessarily be found
         correctly, ie., the normalized peak-height will be a little off from 1.
         Michel is looking into that.

         Sven has written a new package called LArTBTiming. Lots of
         many-page emails with details have gone back and forth betwen
         Sven and Michel on that.
         LArTBTiming usues many of the same things that are used in
         LArHECTBAna. It is self-contained and produces time-constants by
         looking at all the cells. First it determines a precise timing
         for the entire event, and that timing is then used for digital
         filtering. The next step in the procedure will be the synchronization
         with the weights.
         In there future there will have to be a different timing file for
         each weights file.