Event finding in GEM T racker Radoslaw Karabowicz 1 - - PowerPoint PPT Presentation

▶
event finding in gem t racker
SMART_READER_LITE
LIVE PREVIEW

Event finding in GEM T racker Radoslaw Karabowicz 1 - - PowerPoint PPT Presentation

Jan 26, 2023 264 likes •596 views

Event finding in GEM T racker Radoslaw Karabowicz 1 Introduction This is a continuation of my presentation from PANDA Collaboration Meeting on 26th June 2013: GEM T racker Status with following: Conclusions:

slide-1
SLIDE 1

Event finding in GEM T racker

Radoslaw Karabowicz

1

slide-2
SLIDE 2

Introduction

  • This is a continuation of my presentation from PANDA

Collaboration Meeting on 26th June 2013: “GEM T racker Status” with following:

  • Short summary of this talks follows:

2

Conclusions:

  • Event-based reconstruction not enough in the time-based reality
  • Some changes applied to reconstruction chain
  • Improved results:
  • track finding ‘efficiency’: 57.79% increased to 87.31%
  • event reco ‘efficiency’: 80.55% increased to 95.20%
  • Further improvements necessary
slide-3
SLIDE 3

Time-based input for reconstruction

Event-based data TTree

  • Ev.1 data

Ev.2 data Ev.3 data Ev.4 data Ev.5 data

Input time slices for reconstruction

  • Slice 1
  • Slice 2
  • Slice 3
  • Slice 5
  • Slice 4
  • Time ordered data in FairWriteoutBuffer
  • time

MC Event begin Data

3

slide-4
SLIDE 4

GEM data’s time distribution

Data yield from different time slices presented in different colors (slicing by TimeGap(20ns) ). 3500 time [ns] 4000 Data yield from different events presented in different colors, vertical lines represent the begins of events.

4

slide-5
SLIDE 5

Time-based reconstruction

  • Changes to code:
  • very few changes to cluster finder
  • hit finder: find hits on front/back pad plane as

before, REQUIRE confirmation on back/front pad plane (check if relevant strips were activated in the previous 100ns - it requires storing information from previous time slices, achieved by PndGemMonitor)

  • track finder: use these confirmed hits for tracking

5

slide-6
SLIDE 6

T rack finder results TB - momentum resolution

Δpx/px 0.99% Δpy/py 1.07% Δpz/pz 3.66%

  • Fitted function: sum of two gaussians
  • Resolution: sigma of the thin gaussian

10000 DPM events

6

slide-7
SLIDE 7

T rack finder results TB - track finding efficiency

87% for primaries with |p|>1GeV/c,

  • compared to ~95% in event-based reconstruction,

improved from 58%, when EB code used in TB mode.

MC track |p| reconstructed track |p| MC track pphi reconstructed track pphi MC track ptheta reconstructed track ptheta

10000 DPM events

7

slide-8
SLIDE 8

Event finding

  • Use the tracks’ start-time
  • T

racks with start-time closer than 3 ns end up in

  • ne event (3ns come from the tracks start-times

correlation), with event time set to a mean of constituent tracks’ start times

  • Even one track can form event
  • Compare reconstructed event times with MC

event times, if the difference is smaller than 5 ns the MC event is considered to be reconstructed

8

slide-9
SLIDE 9

Event building - example

dots - event start time: red - event without MC points in GEM green - event with some points in GEM magenta - not-reconstructed event blue - reconstructed event 9 thin & color lines - GEM digi distribution thick lines - tracks start-time

slide-10
SLIDE 10

Results - event finding

reco time - MC time [ns]

  • 10000 DPM events

simulated.

  • 8165 events with

reconstructable track in GEM tracker.

  • 7536 events

reconstructed (92.3%).

  • 139 ghost events (1.8%).

10

slide-11
SLIDE 11

Reconstruction speed

time to reconstruct 10000 events [s] empty task clusters hits tracks

REAL TIME REAL TIME -

  • empty task time

11

slide-12
SLIDE 12

Event building

12

slide-13
SLIDE 13

Event building

  • GEM T

racker Event Builder

T rack Buffer

Find Events

Event Buffer

Build Event

Store Event T racks

Analyze tracks and extract possible events Store tracks in buffer Store events in buffer Check if no more data expected for the event Store event and corresponding tracks

time slices

  • f tracks

events with tracks 13

slide-14
SLIDE 14

Generalize the idea

  • Several different ways to extract event start

time possible

  • Some of these tasks will not need to store any

data

  • Some tasks will only be storing data to already-

found events (they are not able to reconstruct events)

  • Few tasks will require event start time (t0) to

reconstruct data

14

slide-15
SLIDE 15

Example: GEMEventBuilder

  • vector<FairRecoEventHeader*> FindEvents()

this function looks into input data (GEMT racks) and tries to find possible events. The data is stored in the internal buffer (thanks to derivation from FairWriteoutBuffer), found events are return;ed.

  • void StoreEventData(FairRecoEventHeader* recoEvent)

the function looks into data in the buffer and writes the data corresponding to recoEvent to the output TClonesArray.

15

slide-16
SLIDE 16

Event Builder Manager

  • Internally has a vector of event builders
  • Contains buffers with reconstructed events
  • In the Exec(), it:
  • loops over event builders and calls

FindEvents() function

  • analyses reconstructed event buffers and

creates events

  • for each created event it calls

StoreEventData() function

16

slide-17
SLIDE 17

General idea

  • PANDA Event Builder Manager

Event Buffer

Build Event SciTil data events global tracks GEM tracks MVD data

Find Events

Global T rack Buffer

Find Events

GEM T rack Buffer

Find Events Store Event Data Store Event Data Find Events

DIRC data DIRC Rings Buffer

Store Event Data

17

slide-18
SLIDE 18

Already implemented

  • PANDA Event Builder Manager

Event Buffer

Build Event event header events GEM tracks

Find Events

GEM T rack Buffer

Find Events Store Event Data

PndGemEventBuilderOnMCEvents PndGemEventBuilderOnTracks

18

slide-19
SLIDE 19

Usage

  • The necessary changes to PandaRoot can be

taken from: svn/pandaroot/development/

karabowi/eventBuilderDec2013

  • The code will be available in the trunk soon.
  • Macro:

// ----- Event Builder ------------------------------------- FairEventBuilder* eventBuilder = new FairEventBuilder("Event Builder", 0);//verboseLevel); fRun->AddTask(eventBuilder);

  • PndGemEventBuilderOnMCEvents* gemEBOnMCEvents = new PndGemEventBuilderOnMCEvents("GemEBOnMCEvents",0);

eventBuilder->AddEventBuffer (gemEBOnMCEvents); PndGemEventBuilderOnTracks* gemEBOnTracks = new PndGemEventBuilderOnTracks ("GemEBOnTracks",0); eventBuilder->AddEventBuffer (gemEBOnTracks); // ------------------------------------------------------------------------

  • // ----- Intialise and run --------------------------------------------

fRun->Init(); fRun->RunEventReco(0,nEvents);

19

slide-20
SLIDE 20

Few comments

  • The output is organised as follows, to mimic as closely as

possible the original structure of the data:

  • RecoEventHeader. Each entry in the TT

ree has an object of FairRecoEventHeader, where currently:

  • fEventTime,
  • fEventTimeError and
  • fIdentifier
  • are stored;
  • TClonesArrays with the data.
  • fIdentifier - to easily identify, which event builder was

responsible for the event creation.

20

slide-21
SLIDE 21

Few comments cont’d

  • PndGemEventBuilderOnMCEvents has nothing to do with

GEM, I just developed it in gem/. The name should be changed.

  • Naming problem:
  • currently the EventBuilderManager is FairEventBuilder.

Maybe it should be renamed to FairEventBuilderManager. There should be different implementations for different experiments, that will differ in analysis and extraction of events.

  • the task’s event builders derive from FairEventBuffer. They

are actually responsible for event finding, storing task specific information in buffer, and writing them to the

  • utput TClonesArrays. It’s a lot of responsibility but why to

split it? Maybe eventually FairEventBuffer will have to be renamed to FairEventBuilder.

21

slide-22
SLIDE 22

Results

22

slide-23
SLIDE 23

Results cont’d

  • Difference between reconstructed event time

and GEM track time stamp

23

slide-24
SLIDE 24

Results cont’d

  • nly Ideal

EventBulder (3106)

  • nly GEM

EventBulder (128) combination

  • f both

(6892) 24

slide-25
SLIDE 25

Summary

  • A proposal of the Event Builder task structure

is available.

  • It can be easily extended with more event

builders.

  • Discussion needed to include more use cases.

25

slide-26
SLIDE 26

channel number

time [ns] 26

slide-27
SLIDE 27

Without deadtime

time [ns] 27

slide-28
SLIDE 28

With 100ns deadtime

time [ns] 28

slide-29
SLIDE 29
  • riginal hit

finding:

20ns time frames

29

slide-30
SLIDE 30

hit finding after changes for TB

30

slide-31
SLIDE 31

Events 28, 29, 30

For comparison: MC points from corresponding MC events

Events 41, 42, 43

31

slide-32
SLIDE 32

PndGemT rackFinderOnHitsTB

FindTrackSegments() Double loop over hits to match close hits from different stations. Assuming start vertex as the third point, track parameters (momentum, theta, phi) are calculated and track segments are formed.

input array

  • f hits

track segments

MatchTrackSegments() Match track segments with similar parameters to find track candidates. RemoveCloneTracks() Check track candidates for bad tracks. Criteria for bad tracks are:

  • track segments too different,
  • small number of track segments,
  • many hits shared with other candidates.

Remove bad track candidates. CreateTracks() Surviving candidates form output array of tracks.

track candidates track candidates

  • utput array
  • f tracks

32