Moore Phone Meeting 11/03/04

 

Participants: Alan Poppleton, Andrea di Simone, Andrea Ventura,
Armin Nairz, Daniela Rebuzzi,  Edoardo Gorini, Elena Brambilla,
Gabriella Cataldi, Giorgos Stavropoulos, Ketevi A. Assamagan,
Jim Shank, Maaike Limper, Margherita Primavera, Martin Woudstra,
Michela Biglietti, Nectarios Benekos, Natasha Panikashvili,
Stefania Spagnolo, Stefano Rosati, StephaneWillocq, Steven Goldfarb,
Tadashi Maeno.

1- G4 Validation -Discussion with G4 people
  (Daniela, Andrea, Ketevi, Tadashi) in order to begin
  the validation of G4 simulated data.

Daniela reports on the status of digitization, as well as on the
validation studies she did, together with Stefano on reconstruction
of data using the TestBeam setup. The MDT and CSC digitization packages
are working properly in release 7.7.0. The other 2 technologies are
in debug status, and they are foreseen to be available in the next nightlies.
At present there are available in POOL  simulated hits files (7.5.0 release)
and  digitized hits files (7.6.0 release), boths with ATLAS set-up.
Those files are intended as pre-proproduction,  specifically for
validity studies. Using ATLAS setup
there have been exercises from other Moore-developers (Giorgos, Ketevi, 
Gabriella) that tried:
-to read G4 hit containers from POOL, do digitization, and store
DigitContainers in StoreGate and subsequentely to read the digitContainers from
StoreGate and ``use the digits'', for now only simple prints out were 
tried. 
As expected, this procedure works (using RecExCommon environment and
accessing MDT/CSC). More simulated hits files will be available soon
using release 7.7.0 (ATLAS set-up). Also those files are only ``pre-proproduction''
files and a large statistic is not foreseen, until the first validation is
defined. Moreover those file will only work with the release 7.7.0
reconstruction. The jobOptions in the share directories in order to
have publically available the ``running from G4'' procedure will soon be provided.

A point has been put in evidence related to the fact that:

In digitization there is the need to initialize MuonDetDescr
from somewhere.
TDRDetDescrAthenaRoot was initially considered as a
temporary solution till the MuonGeoModel takes over.
In the G4 digitization, this choice is not satisfictory even as a
temporary solution since the AthenaRoot descriptor is built from
zebra (Geant3).  Stefano had implemented
MuonAsciiDetDescrDecoder, for test beam purposes, initializing
MuonDetDescr from ascii. Because of the problems with the
AthenaRoot initialization, as mentioned above, he has
extended the "ascii decoder" to the full muon geometry,
and Tadashi & Yoji added some fixes for TGC amdb P03.
The AthenaRoot initialization has been currently
replaced by the ascii initialization --- until MuonGeoModel.

The initialization from MuonGeoModel is planned to be available 
by release 8.0.0. From this time on, Digitization can use it
fully. From the reconstruction point of view there will be the
chance to start (a staged) migration from
MuonDetDescr to MuonGeoModel.

2- Jim raised the point that an How_to_run procedure should be available 
on the repository and not only on the web-page, in order to simplify
users life. We agreed on the addition of those instructions directly to the
repository. They be available after release 8.0.0

3-Moore results with 7.5.0 on DC1 single muon files and
  comparison with Muonboy results and Moore results
  obtained with 7.0.3 (the last validated release).

The History - In the last Muon Combined session,
Muonboy presented the results with release 7.5.0, using 
single muons files produced  last February (DC1).
When trying to combine with the Inner Detector,
the evidence very bad efficiencies not only in the
CSC region but also in the TGC/MDT region.
Their results are worse than those obtained in
Athens (rel 6.0.3) on the same files.

During the Muon Combined Meeting this problem had
been largely discussed and we need to understand if the
DC1 events are reliable both for the physics group
that want to use muon reconstruction both because
we need a reference point for G4 validation.
The confirming/not confirming these results will allow to 
understand if the problems are in the reconstruction or
in the simulated DC1 events.

The MuonBoy results are reported here.
They run on 2 set of files:

-on one hand, a set of single muons at various pt produced  in February 2003

-on the other hand, set of files produced in Summer 2003

In the plot, there is, eff vs eta at 1000 GeV
(Xkalman eff, Muonbox eff and STACO eff)
for:
1/ the February 2003 file with the Athens version
   the well know problem in the CSC at that time is
   apparent
2/ the Summer 2003 file with 7.5.0 version
   is very nice looking. Eff are very high as
   it should be for a sample without en showera 
3/ the February 2003 file with 7.5.0 version
   despite that 7.5.0 version is used, the situation is     
   worst than it was for Athens. If one looks for the
   Phi matching of ID and MuSpectro tracks, one sees
   that there is a shift. Note that before backtracking the
   Muonboy eff is very high (note that the open points almost
   reach 100%).


Margherita and Monica have been running and analysing separately
the Pt=1000 GeV files.

Monica
1- on february files with 7.5.0:
eff_7.5.01.eps --> (Moore means only Moore while MuID means
MuID combined so there is Moore+iPatRec with the refit). 10000 events.


2- on summer files with 7.5.0:
eff_7.5.0.eps --> There is ``a spike'' at eta=2, that
comparing with MuonBox seems to be only our
(or detector description, or whatever package only used by us)
problem. 

3- on february files with 7.0.1 (equivalent to 7.0.3, for us it is an equivalent to
                                                 Athens version):
eff_7.0.11.eps --> (Moore means only Moore while MuID means
MuID combined so there is Moore+iPatRec with the refit). 1000 events.


4- on summer files with 7.0.1:
eff_7.0.1.eps --> There is ``a spike'' at eta=2, that
comparing with MuonBoy seems to be only our
(or detector description, or whatever package only used by us)
problem. 

Margherita
effeta_comp.ps  --> The MuID combined results  for summer data (above histo)
and february data (lower histo) are reported.

General Note.

on february single muons file we do not see the spike, while this is 
present in every ``physical'' sample file from DC1.

February files have been produced using simulation release 5.0.3 (Alessandro)
Summer files have been produced using simulation release 6.5.0 (Armin)

Margherita reports on the work, and we decided:

1- to check if the problem is still present in 7.7.0 (Nectarios)
2- to study in more detail on a event by event base the ``featuring''
events (eta~2, eta~1).

4- Moore/MuID towards release 8.0.0
Moore-Units migrations - debug - After a few fixes seems that the units migrations is 
working properly on a event by event base.
Nectarious has kindly agreed in running on more statistic, and results will
soon be added to the page. 

MuID- Units migrations - updates - Alan, Michela, Natasha. Also for MuID
seems that the units migrations is working properly on a event by event
base. Unfortunately running on more statistic will only be possible with
MuID standalone, since a memory leak in the InnerDetector is preventing
a proper running on high statistic.


5- Potential projects for new developers, as well as
  planning for the near future-Report from wednesday
  meeting.
(Steve)
Steve reports on the list of tasks that were identified
during the discussion of last wednesday end the
people that could work on the task.

6- First studies on Commissioning using Moore. (Maaike)

  Maaike Limper (graduation student from NIKHEF) has
  been looking at results of running Moore on simulation
  data of cosmics muons for ATLAS Commissioning.
  Information on the used data-files can be found here:
 http://rmcphers.home.cern.ch/rmcphers/atlas/cosmics/

 The following plots were made using cosfile2_001.rz as
 described in the above link, using Moore and comparing it
 to an algorythm Maaike wrote that makes tracks from
 pattern recognition in the rpc-hits.
 The plots give a display of the event(s) in the (global) XY-plane.
 Pink - Moore tracks
 Black and red - Maaike tracks
 (green circle - eta-strip)
 (red circle - phi-strip)"

plots:
  1. Moore_not_ok2XY.gif
  2. Moore_ok2.gif
  3. Moore_tracks_for_1000_events.gif
  4. Maaike_tracks_for_1000_events.gif

7- GeantinoMap-based Material Service. (Armin)
  see write-up in ps or pdf  
  Alan and Armin will work in close collaboration
  in order to solve the problem. The work will start only after
  release 8.0.0.

8- Next meeting.
    A tentative date for next phone meeting has been fixed on:
    thursday March 25th at 17:00 GVA time.