CALICE MAPS Meeting, Birmingham, 21/09/09
=========================================
Present: Paul Dauncey, Owen Miller, Tony Price, Nigel Watson, John
 Wilson
Phone: Jan Strube


Minutes: Paul


Minutes of previous meeting: No corrections.


The meeting was spent going through the previously assigned tasks for
the beam test analysis. The aim is still to have a first pass of the
efficiency analysis, including all effects, completed within four weeks
of the last SPIDER meeting; this means by the first week of Oct.


Run quality: John and Paul have put together a first draft of a run
 quality file. Nigel has also used this to make an xls version. John now
 intends to analyse the values, e.g. studying the distribution of the
 temperature RMS values to find sensible cuts for these. Paul commented
 that some bad runs can only be found by hand from the elog so these
 will need be to read through carefully. Runs where the beam was not
 present, or where it disappeared for parts of the run, will show up as
 having a low ratio of scintillator coincidences to bunch trains, but
 the detailed distribution would need a significant study.

 John will hold the definitive version of the run quality file so any
 required changes should be communicated to him. He will put it onto the
 SPIDER Confluence web pages. There was some discussion of the best
 format for the file but at least the txt and xls versions should be
 available.

 It may be useful to put a summary of the bad pixel lists into the run
 quality file also, e.g. the number of good pixels for each of the six
 layers, so that runs with many bad pixels can be excluded from an
 analysis.

 In general, the idea would be to have quite fixed criteria for
 rejecting runs, so that all remaining runs need to be used for the
 final analysis. This will prevent only using runs which "look" good
 and hence may not be unbiased.


Clustering: Jan reported that there was little progress, due to the
 other meetings he and Marcel needed to go to. He thinks there may be
 some progress by the first week of Oct.


Monostables: Tony had looked at the issue of consecutive hits in time in
 the same pixel. Benedict had previously reported a very low rate of
 such hits, but Tony sees ~40%. This is more reassuring as this implies
 there may not be a large inefficiency due to the monostable lengths.

 Tony showed some plots of hits, with a colour-coding to show the number
 of hits at consecutive times; see usual web page. The colour-coding is
 that black is in the same timestamp as the PMT coincidence, blue is 
 one timestamp later and red one later again. If the shapes are
 overlayed symmetrically, it means the same pixel fired in successive
 timestamps and if they are not, it maybe shows diffusion as the charge
 takes time to spread out.

 Tony will continue this study. One useful plot may be to find the
 maximum number of consecutive hits for every pixel, as seeing two (or
 more) means the monostable length must be > 400ns and hence will give
 no inefficiency. However, this assumes the pixels cannot refire due to
 noise in consecutive timestamps, which may not be valid. (Paul will
 check this with Jamie Crooks.) It might be that the study needs to be
 done for e.g. timestamps > 1000, so as to exclude the most noisy
 pixels.


Imperial tasks: Paul showed some slides of progress, see usual web page.

 For determining the rate of bad tracks, Owen suggested cutting out any
 tracks which are not closely parallel with the z axis. This should help
 but a quantitative measure will be needed eventually. Trying to use the
 out-of-time hits in the track-finding would be messy but might be the
 way to determine this.

 These initial estimates of efficiency unfortunately show that the
 standard threshold of 150TU for the four outer sensors was probably
 not optimal, as it gives only ~50% efficiency compared with ~80% at
 thresholds around 170TU.


Birmingham tasks: Owen also showed some slides of progress, see usual
 web page. He has so far concentrated on run 447830 which has low
 thresholds in the inner sensors; this might explain the low efficiency
 he sees.

 Before the beam test started, he had released two functions which will
 flag pixels which have memory full at the end of the bunch train. These
 can be found at
  https://heplnm061.pp.rl.ac.uk/display/spider/Testbeam+Analysis
 The plots shown do not include this correction yet.


Other items: There were some other items which were assigned lower
 priority at the last meeting but should still be done at some point.

 Tony has started on the monostable length study.

 The temperature variation could be studied by comparing runs with
 the same nominal thresholds but at different temperatures.

 The cluster comparison with MC and the shower studies both need MC,
 and are therefore delayed until the MC is ready.

 The beamline material investigation is possibly not needed for some
 time.


Next meeting: By phone on Thu 1 Oct, starting at 14.00