Moore Phone Meeting 05/11/03

 Participants: Alan, Armin, Gabriella, Giorgos, Kyle, Michela,
Francesco, Steve A.,Steve G., Natasha, Monica, Luca, Ketevi, Jim.

MuonIdentification for low energy muons (Monica, Natasha, Theodota)

Monica- A first study on selection efficiency of low pT muons for Moore Vs TileID
is reported. The description can be found here.

Theodota-  Unfortunatly the connection to Thessaloniki is not possible.

Natasha- Work on  identification of low pt (see presentation at last soft week)
Work is going on testing the algorithm.
Besides, she has reconstructed with release 7.0.1 the
dataset(pp-->J/psi(mu(6)mu(3)) that was re-simulated with
atlsim 700.01. She prepared the results of MOORE andMUID
efficiency in this case. The efficiency in the forward region
looks better than in the previous cases.
But the problem in the eta ~ 2 region ( it is region between CSC chamber
and MDT chamber in the inner station) is still there.
A preliminary version (not yet complete) of the presentation for the muon week is
available. also in pdf

MuId-Moore comparaison using Artemis (Kyle)

I have two groups of plots. They both come from running over vbf Higgs
H->tau tau. Approximately 28.7% of the events will have exactly 1 \mu and
3% with 2 \mu's. This would lead to a mean of 0.347 for the number of
muons in an event if there was 100% effeciency.

muons.ps -- just ran this morning, only 1000 or so events, but fixes
problem in my muonbox interface ( pt -> abs(pt) )

muons.save.ps -- ran last night, has ~9000 events, \eta for muonbox is
actually charge*\eta (can tell on page 5). Except for that, the plots are
the same and this file has 10 times more events.

The strangest thing I see is the pt of mu's with moore seems to be about
2.5 GeV > than atlfast, muid, muonbox. This may be part of my problem
with MissingET, b/c I have to correct for the Muons by hand - and my
MissingET is shifted from the truth.

I am very new to muons, and I could not find documentation about an
"accepted way" to compute 4-momenta from the many parameters that are
available. For documentation, here is what I am doing... please tell me
if it is wrong.

For MuonBox:
I take from TDS <MB_TrackStoreTDS> and construct
MBTrackAdaptor::MBTrackAdaptor(MB_Track* tr):
m_assocs(Assocs()){
m_tr = tr->GetTrackAtPerigee();
double pt = fabs(1/m_tr.InverseTransverseMomentum());
double phi = m_tr.PhiAtPerigee();
double theta = atan(1/m_tr.CotgAtPerigee());
if (theta < 0) theta = theta + M_PI;
double px = cos(phi)*pt;
double py = sin(phi)*pt;
double p = pt/sin(theta);
double pz = p*cos(theta);


For Muid:
I take from TDS a MuidTrackContainer and construct
MuidTrackAdaptor::MuidTrackAdaptor(const MuidTrack* tr):
m_assocs(Assocs()),m_tr(tr){
if( tr->fit_quality().fit_code() == 0) {
double px =
m_tr->perigee_parameters().cos_phi()*m_tr->perigee_parameters().abs_pt();
double py =
m_tr->perigee_parameters().sin_phi()*m_tr->perigee_parameters().abs_pt();
double p =
m_tr->perigee_parameters().abs_pt()/m_tr->perigee_parameters().sin_theta();
double pz = m_tr->perigee_parameters().cos_theta()*p;


For Moore:
I take from TDS a MooTrackContainer and construct
MooreTrackAdaptor::MooreTrackAdaptor(const MooiPatTrack* tr):
m_assocs(Assocs()),m_tr(tr){
double px =
m_tr->perigee_parameters().cos_phi()*m_tr->perigee_parameters().abs_pt();
double py =
m_tr->perigee_parameters().sin_phi()*m_tr->perigee_parameters().abs_pt();
double p =
m_tr->perigee_parameters().abs_pt()/m_tr->perigee_parameters().sin_theta();
double pz = m_tr->perigee_parameters().cos_theta()*p;

Higgs into 4 muons analysis  (Theodota)

Theodota is not at the phone, please have a look at the following results
and send your comments to Theodota.

results of 7.0.1 Muid/Moore from a Higgs(130 GeV) sample of about 11000 events

1. The efficiency versus eta and pt from single higgs muons (7.0.1)
2. The resolution of the MUID reco Higgs mass without and with Z
constraint (7.0.1) and
3. The resolution of the MUID-MOORE reco Higgs mass without and with Z
mass (7.0.1)
4. The resolution of the MUID without and with Z constraint and for
and MUID-MOORE reco Higgs mass without and
with Z constraint with version 6.0.3

Geantino map based material service (Alan, Armin, Luca)

The Geantino map based material service is now in release 7.2.0
(thanks to Armin and Alan for caring about compilation
phase, tag and so on).  As pointed out in the last phone meeting
the service is in Debug status and it is not yet finalized for
physic studies

Luca tried to run the new service,  and he has a first round of
debug plots. The work must follow in close contact with Armin.

Technical side.
(Alan) In the Geantino Map service Armin's datafile is used from MooAlgs and
MooEvent. It would fit better in MooUtils/share than its current location
in Moore/share. We shouldn't have anything but sub-packages
in a container package.

(Gabriella) I perfectly agree with Alan and I would propose also in
Moore the introduction of a MooUtils package. Moreover this
would allow the introduction of classes (RZSegmentMaker,
PhiSegmentMaker) that are practically duplicated in Moore and
TrigMoore. Allowing a easier maintanenco of the package.
Once a work on the code is accomplished, this should also include
the Material Map Service (Parametrization and  Geantino Map) coding in
agreement with an Athena Svc (as proposed ages ago by Giorgos).
When should this work start? ...............

Test Beam (Stefano)

Ketevi added the access methods in MuonDigitPosition to allow the use of the
s value, available in MuonDetPosition. The problem with LineFitter for chambers
having s<>0 has been solved and the fix is in 7.2.0

The possible choice of accessing the conversion service from DigitToHit for the
Test Beam data has not yet been inserted (it will come into 7.3.0)

Persistency (Giorgos and Alan)

Introduction( from David Quarrie - Gabriella mail exchange)
The basic POOL  persistency support has been available since release 7.0.0,
with one  major missing functionality (support for DataLink and ElementLink). 
Several bugs have also been found and fixed for 7.1.0, surely that  this will
continue into the future. Several classes have been  persistified using this
restricted functionality, and it's possible  that the classes that you are
implicitly referring to might fall into  the category that can be handled by
what's available now.

The missing functionality is scheduled to be available at the end of  the month.
Unfortunately that probably means just after 7.2.0 rather  than just in time for it,
but if that schedule is maintained, you  should be able to persistify your EDM
for 7.3.0. (Is this the case?)

One thing to bar in mind is that if we write out any data with a  release having
restricted functionality, you won't be able to read it  back in again with any
release after the persistency is upgraded. For  example, say you run a job based on
release 7.1.0 which writes out some  tracks but omits the links to
any hits because the ElementLink isn't  supported. Now assume POOL support
is upgraded for release 7.2.0 so  that the tracks and hits can be written out.
Now you're in a situation  where only jobs based on release 7.1.0 can read data
written with that  release, and only those based on 7.2.0 can read those
written by 7.2.0.  Clearly this is a situation that cannot be used for bulk
production, so  the goal is that sometime before DC-2 we stabilize the
EDM and  persistency support. During that period,
support  for schema evolution is scheduled to be added to POOL, which
should 

(Status and plans)

Giorgos and Alan-
We do not need DataLink or Symbolic Link, at least not as a first item.
See previous phone meeting, but CLHEP matrix support is not there and
as reported in the last meeting:

Moore-MuID-TrigMoore in 7.2.0  (Alan, Armin, Gabriella, Michela)

MUID in 7.2.0 (Alan):
       1. jobOptions in Install Area
           2. SG access const correctness
         3. added some forward declarations and removed some unnecessary includes
         4. removed all references to DataHandle
         5. upgraded to new MCcollection interface

MOORE in 7.2.0 (Alan, Armin, Gabriella, and David Rousseau suggestions):

                                   
Added specific includes of DetectorPosition in MooXxxHit.cxx .
          #include "MuonDetDescr/MuonDetPosition.h"
       1. the structure of includes is such that there is only a forward declaration
            of MuonDetPosition.
            Hence the compiler has no way to know that MuonDetPosition derives
            from DetectorPosition.         
           // WARNING: to be included in : XXX_DetDescrElement.h ????

          2.  Geantino Map - code and file (see above)

          3. HepMC GenEvent change (in MooStatistics)

TrigMoore in 7.2.0 (Gabriella, Ketevi and Michela):
   

Milestones and Plans  (All )

We went to the muon WBS as it is and its contents
on the reconstruction side:

Comments on milestones:

7.2.0 status- (from Ketevi) Daniela Rebuzzi implemented the
G4 MDT digitization Ketevi did for the CSC, all tagged for 7.2.0.
Yoji is doing it for the TGC and Andrea DiSimone for the RPC.
The TGC and RPC work is not yet as advanced as the
MDT and CSC which are completed now, just waiting to be tested.

For 7.3.0, Ketevi and Daniela will validate the MDT and
CSC G4 digitization using G4 hits generated using Pool.

After that, MOORE and Muonbox can take over to see
what happens in the reconstruction.
So only after validation 7.3.0 we can think to stage the work on 
reconstruction of G4 data (note-probably at that time there will be
yet no RPC and no TGC fully validated in)

MUID (from Alan)

There are other Muid things (..... more relaxed timescale):

1. SG lock output collections

2. package reorganisation with container package

3. SG output of cross-reference table for all candidate muons: iPatTrack to MooTrack, TileMuon, MDT/RPC/TGC/CSC segment and combined fit parameters and matching quality. This is in the context of softMuRec and will give a common output and allow for ambiguities (that unfortunately exist at low pt). I would see this as the persistent Muid o/p.