26 Jan, 2004 1

MEG Software Status

Framework for MEG MC,Unification of LargePrototype/beam test,

Scheduleand

DC reconstruction

MEG Software Group

26 Jan, 2004 2

Framework for MEG MC

26 Jan, 2004 3

Framework for MEG MC(1)

• Unified framework with double option:– Tokyo or Pisa code,

• Framework based on:– Fortran 77,– CERNLIB,– ZEBRA,– GEANT3,

• Distributed via CVS.

26 Jan, 2004 4

Framework for MEG MC(2)

• Tree structure & skeleton … ready;

• Materials & tracking medium … merged;

• Event generator … stand alone & built-in;

• DC, TC, Magnet and B field … merged;

• ZEBRA structure … in progress;

• Scintillation photon tracking … in progress.

26 Jan, 2004 5

To be done: MEG MC

• Merge Liq. Xe Geometry;

• Test of reduced number of PMT in Liq. Xe;

• Digitization for all the sub detectors;

• Full reconstruction program;

• Offline database… ODB? Separate database (e.g.PostgreSQL, MySQL, etc.)?

26 Jan, 2004 6

LargePrototype/beam test

26 Jan, 2004 7

LargePrototype/beam test unification(1)

• MC Merge into the new framework… just finished.– Common output format for DATA/MC;– Scintillation photon tracking in Liq. Xe

… Full ray tracing or geometrical tracking;– Reflection on the PMT quartz window

… Fresnel or total reflection;– Scintillation light spectrum

… Monochromatic, Gaussian, Basov et.al, etc.– Rayleigh scattering/absorption in Liq. Xe.

26 Jan, 2004 8

LargePrototype/beam test unification(2)

• Analyzer– NaI calibration/gain correction

… merged;– NaI vertex/energy reconstruction

… stand alone program, merging into analyzer being in progress.

26 Jan, 2004 9

To be done: LargePrototype/beam test

• NaI response simulation;

• LiH target and Vessel simulation;

• phase space simulation for 0;

• Offline database … ODB? Separate database (e.g. PostgreSQL, MySQL, etc.)?

26 Jan, 2004 10

Schedule/man power• Will be discussed in the Software meeting

and reported in the review meeting.

26 Jan, 2004 11

DC reconstruction• Track Dictionary

– Efficiency– Resolution

• L-R ambiguity solution

26 Jan, 2004 12

Several tracks with similar kinematics

producing a single hit pattern

Hit pattern

Single and unique string(i.e. a dictionary key)

Average (over the set) track parameters

The dictionary concept

Several tracks with similar kinematics

producing a single hit pattern

Several tracks with similar kinematics

producing a single hit pattern

Several tracks with similar kinematics

producing a single hit pattern

26 Jan, 2004 13

The track dictionary is a ordered list of records:

Key (hit pattern) average track parameters + rms

The track dictionary exploits the “digital” response of the spectrometer

NO Tdrift usedNO z measurements used yet

26 Jan, 2004 14

MC sample used to build the dictionary:

• Positrons from Michel decay;

• Unpolarized muons;

• Generator level cuts: 0.08 < |cosθ| < 0.35;-60° < φ < 60° .

26 Jan, 2004 15

The population of the patterns is not uniform: 40% has 1 entry 43% has 2 ÷ 10 entries 13% has 11 ÷ 50 entries 4% more than 50 entries

Number of events in a dictionary record

250000 generated events 12900 patterns; efficiency = 95%

26 Jan, 2004 16

Momentum componentsfor events in the dictionary

Event by eventdistributions

Average in eachDictionary record

Track first turn has hits in at least three sectors

Px / MeV Px / MeV

Py / MeV Py / MeV

Pz / MeV Pz / MeV

LEFT RIGHT

26 Jan, 2004 17

The comparison of the distributions of an average parameter in the dictionary with the actual parameter distribution shows:

• Px and Py have similar shapes;• Pz

• a hit pattern in the spectrometer cannot tell the sign of Pz;

• the shape of the distribution of |Pz| is not well reproduced

poor |Pz| resolution of the dictionary.

pMC - < pdict > σ

Generate a sample of independent events

For tracks in the dictionary acceptance (Nsectors > 2)

find the dictionary keycompare;

Px with <Px>(key);normalize to RMS<Px>

vertex X

vertex Y

vertex Z

Px

Py

Pz

What is the dictionary “resolution” for all parameters ?

26 Jan, 2004 19

To be done: dictionary

• Optimize stats. given by 1 – eff. ~ 10-3 - 10-4 and by looking at RMS vs. stats. (intrinsic resolution of method);

• Add noise hits;

• Add inefficiency of Drift Chamber;

• Add drift time;

• Superimpose tracks.

20

Starting from digit ID and drift time, in each sector we have 4 possiblesolution (4 tangent segments)

Digitization of the MC hitfrom x,y,z to: number of sector (1-17), number of chamber (1-2) number of wire (1-9) D.C.A(digit) smearing of 200m Tdrift (const Vdrift) Z(digit) smearing of 300m

First reconstruction stepdrift circle

LEFT – RIGHT AMBIGUITY SOLUTION

26 Jan, 2004

P

Q

T

The assumption: track ~ circle with centre in Cif PT and QT are straight segments tangent to C and intersecting in point T, then α = α´

The strategy: select the right tangents in two consecutive sectors by choosing the pair giving the minimum ´

Intrinsic limitations:• non uniform B implies that

tracks are not exactly circles • drift distance resolution

‘

C

’

26 Jan, 2004 22

The plot shows the distribution of for 1000 tracks

All possible combinations (23097)

Exact combinations (3778)

We need to define a cut on

which allows to keep high efficiency for

correct left-right choices and to reject wrong

combinations

rad rejects57% of the incorrect

solutions

26 Jan, 2004 23

efficiency

With Δα = 0.24 rad we reach90% of total efficiency in L – R solution.

By definition, the total efficiency comes from two terms:

-Tracks where the L – R ambigurity is solved in each sector (60%);

-Tracks where the L – R ambigurity isn’t solved only in 1 sector (30%) cut

Efficiency vs

26 Jan, 2004 24

To be done: L-R Ambiguity solving

• improve efficiency, evaluate timing;

• study the effect of resolution varying with the impact parameter;

• use the “calibrated” digits, (i.e. x,y.z as estimated after left-right ambiguity resolution) as starting points for F. Cei’s algorithm estimating track parameters.

A long term plan once a fit algorithm is defined

• Get dictionary output – if the hit pattern corresponds to a key – when/if the resolution is appropriate for the fit (save

computing time)

go to the track fit

• Solve left-right ambiguity – if the track is not found in the dictionary – if the hit pattern gives ambiguous track parameters

(high combinatorial calculations only when needed)

go to the track fit

else