(present: AA, MF, IG, TI, NK, RK, ML, TS)

Status Reports
Tayfun is working on theoretical calculations of the shower shape. He is implementing the z-position of the beam counters in his code and (assuming their xy-position is zero), with Margret's compilation of z-positions, should now have the information to see whether a beam particle goes through the trigger counters.
Michel suggests that calculating many beam particle trajectories might unveil a cross-over in the region of the F1/F2 counters. But then again, the trajectories might be parallel enough that it won't...
In the following discussion, Alan wanted to know what sort of things had been calculated in the design of the calorimeter - e.g.: sampling fraction of em shower as a function of eta and X0 in depth as a function of eta. A number of these things have been done and are documented in the TDR and TNs. But what hasn't been done is a calculation of them in the non-pointing geometry of our testbeam, although Margret has made calculations of X0 as a function of R and depth in the non-pointing geometry and Tayfun has her code to be transferred from Fortran into C++.

Tamara Has calculated distributions of occupancy based on ped_rms and on noise. She promised us nice plots for the next meeting. She is also working on finding out what level of occupancy to use for a cut-off. For that she is is looking at the change in resolution for various cut-offs. Evaluating this should prepare the base on which to build her thesis.

Margret is in the midst of re-writing her code in TBRootAna and finds that it makes writing the code a lot easier, more flexible and neat. (Ian thoroughly deserves to indulge in some gloating!)

Naoko Showed us a number of plots she made based on the 119 GeV e runs taken at 9 impact locations with 3cm shift between them. She used the 2D touching neighbours (incl corners) method to determine clusters. She rejected events with bad global timing and random triggers. The plots she showed were:
Etot[nA], fit with an asymm. Gaussian. The asymmetry is about 50%, but at this point, not much should be read into this. The resolution is 1.3%, which is consistent with Hendrik Bartko's results.
Reconstructed x-position vs beam chamber x-position.
Global timing[ns]. There appears to be a phase-dependent error of the weights parametrization.
This results in 2 peaks when plotting the response vs the global time, and has an effect of approx. 6%.
Alan was wondering how a 6% spread can still give a resolution of 1.3%. The answer appears to be in exactly how the plot is populated. Naoko will look into that to make it more clear.

Ian reported recent changes on the nearest neighbour methods. Ian also reported on the new TBRootAna options -E and -H recently implemented by Michel. They allow files containing list of data file names to be used. The best place to look up all the improvements is on TBRootAna web-page under the Aug.7 news. The public release of TBRootAna is planned for the end of the week.

Michel has done a lot of work on new methods in the Geometry package (as was shown in Ians presentation). The volume and centroid calculations are finished now. During a telephone conference with the LAr software group just before this testbeam meeting he presented the capabilities of the package. People were very interested in Michel's volume calculation and it turns out that nobody else at Cern or elsewhere has done anything nearly as detailed in this area so far.
Michel also continued to investigate problems with noise, and found that there are 2 categories:
a) Cells with non-Gaussian noise behaviour (mainly in the HEC)
b) Noisy cells (predominantly in the EMEC), whose mean is shifted, i.e. their pedestal calculation is not accurate.
He found that there can be a 15-25 nA offset in a Gaussian that should be located at zero. This raises the occupancy of the cells.
Richard suggested to have a look at the pedestal files and see what they tell us. Michel singled out run 1024 and asked Naoko to check the pedestal calculations for that run.

Questions
Tayfun wanted to know whether there are any random events and how to track them down. He noticed that some runs don't appear to have any random trigger bits set - is that because there are no random events? Or is it a result of bad global timing? A firm answer to his question could not be given at this point.

The meeting then ran out of time and lunch was put on the agenda.