Blog from April, 2012

This page presents an attempt to use the trigger TEM diagnostic information to recognize calorimeter ghost signal.
Pass 8 Recon & Analysis Upgrades Weekly Meeting Agenda

Summary

Code and method
Overlay energy for tagged clusters (MonteCarlo AG)
Efficiency with Periodic Triggers
Effect on Flight Data IMPORTANT
Ghost number and cluster classification
Event display

Information available

The TEM trigger diagnostic information provides trigger information on CalLo and CalHi per each layer end.
From Sasha:

The code example for accessing CAL diagnostic info I can recommend you is the algorithm from calibGenCAL package used for trigger thresholds measurement:
/afs/slac/g/glast/users/chehtman/calibGenCAL_analysis/calibGenCAL/calibGenCAL-05-06-00/src/lib/Algs/LPATrigAlg.cxx
The method
LPATrigAlg::fillTrigBitArray()
just extracts CAL trigger bits from a digi file and puts them into some local structure.
As a reminder, CalLo is at 100 MeV and CalHi at 1 GeV.

Analysis

Code and method

Starting from Sasha's example, I wrote a piece of code that does the following:

open digi, recon, merit and relation files
reads digi to create two arrays of layer end trigger bits [tower][layer][face] , one for CalLo and one for CalHi
open recon and loop on clusters, then for each cluter
1. open the corresponding crystal collection
2. check if any crystal end has more than 100 MeV (or whatever other threshold)
3. if any, then look if the corresponding layer end has a trigger bit set
4. if not so, fill in a map of missing trigger bits and add 1 to a so called "cal ghost number"
for each cluster, the higher the ghost number, the higher the probability that it's a ghost... but it looks like that above 2, they're all ghosts.

Basic version of the code: tagghosts.C
- Another version of the code, algorithm is the Johan's one, but output is a tree with number of tagged xtals and sum-of-energy of tagged xtals for the first 3 cluster tagghosts_v1.C .

Overlay energy for tagged clusters (MonteCarlo AG)

I run the tagghosts_v1.C on the 100 AG-GR-v19r4p1gr14-OVL, and looked at the Overlay energy in the first and second cluster vs. the ghost-tagged energy.
The selection is just trigger and filter and CalNumClusters>0. I also required that there is at least 1 tagged xtals, if there are no such xtlas there is nothing to say.
Few details on the algorithm:

There are two tagging options: conservative (if both xtal ends are ghost-like) and permissive (if at least one xtal end is ghost-like).
- I used permissive since purity is high and efficiency looks low (see below).
The energy threshold for tagging a xtal end is set to 120 MeV (no good reason for this number, need to be optimized).

Here the plots for first (left) and second (right) cluster.

The next step is check if we can lower the energy threshold down to the nominal 100 MeV to increase the efficiency.
If the energy is too low we can tag good xtals as ghost.
I made few reprocessing of the AG-GR-v19r4p1gr14-OVL with threshold at 120, 110, 105, 100 MeV, and plotted the Overlay energy fraction in the first cluster vs. the fraction of ghost-tagged energy.
Same selection as before, including the request of at least one tagged xtals.
The plots below show the permissive case (left) and the conservative case (right) for the 4 energy thresholds.

The higher the number of events in the plot, the higher the efficiency we can expect.
Note that the conservative case is always worse than the permissive case.
In the highest efficiency case (permissive, 100 MeV), there are few events with overlay energy = 0.

My personal best choice, among these, is permissive 105 MeV. That's why I put another plot here:

My first conclusions are:

Johan algorithm works fine!
Clusters with at least one ghost-tagged xtal tend to have large overlay energy.
Only in one case the overlay energy is 0 and there is some ghost-tagged xtal (mostly connected to the energy threshold). The 'purity' of such selection is ~1.
- Efficiency is low. We can't tag a good fraction of ghost clusters in this way. (this was just the energy dependence of the efficiency, no request on min overlay energy here)
There are few events with low overlay energy and low ghost-tagged energy. After looking at event displays I think we can consider good cluster is the ghost-tagged energy is <~3%
- My suggestion for ghost tagging ghost clusters is "TagGhostNumXtals>0 && (TagGhostRawEnergySum/CalRawEnergySum)> 0.03"
- This is valid for permissive E >= 105 MeV.
We can include this algorithm just after clustering, and then tag ghost clusters. Not sure how we should use this info:
- Select best cluster only if non ghost-tagged - what happen if the best cluster is also a ghost (i.e. there are no other options?)?
- Use this info in tracking ( e.g. knowing that the direction is likely to be wrong). Need Tracy here...
- Use in event-level analysis to select events with useless cal information (and treat them as tracker only if possible)

Efficiency with Periodic Triggers

I used the periodic triggers in the Calibration datasets (provided by Johan) to test the efficiency of a pure sample of ghosts.
The dataset used is Periodic_CalGhost, 50 files reprocessed with v19r4p1gr07 (not the latest, but the most recent in the DataCatalog ). It has a cut on Cal deposited energy > 5 MeV.

The efficiency plot is easy: number of events selected by "TagGhostNumXtals>0 && (TagGhostRawEnergySum/CalRawEnergySum)> 0.03" divided by the total number of events.
The the plots for the permissive case (left) and conservative case (right):

The max efficiency is ~84% is reached after RawEnergy ~ 3 GeV.

I checked the effect of the request of some fraction of ghost-tagged energy (if looked necessary from AG hand scan).
The scan from 0 to 3% is in the plot below:

The effect is on the high energy side (>10 GeV) and reduces the efficiency of few percents.

Effect on Flight Data

A test sample is selected in order to see the effect of tagging algorithm on real gamma-ray in flight data

I reprocessed the first 1.5M event of a single full run with a lot of Earth Limb in it: r0324551768
Digi/Recon/merit are taken from DataCatalog, so no pass8 reprocessing is applied (not important for this test).

A cut is applied to select good gamma rays:
"FswGamState==0 && TkrNumTracks > 0 && CalEnergyRaw > 5 && CalCsIRLn>4 && CTBCORE>0 && CTBBestEnergyProb>0.1 && CTBClassLevel>2 && FT1ZenithTheta>112 && FT1ZenithTheta<115"

Cal xtals are tagged with the most conservative algorithm described above: energy >120MeV and no cal_lo trigger in both xtal ends.

Top panel of plot below shows the distribution of (log10 of) deposited energy for:
all sample, events with at least 1 ghost-tagged xtal, events with at least 1 ghost-tagged xtal & > 50% of ghost-tagged energy fraction

Bottom panel of plot below shows the correlation between number of ghost-tagged xtals and ghost-tagged energy (zero suppressed)

It looks like that almost all good gamma events have at least one ghost-tagged xtal and even requiring a large ghost-tagged energy we select a large fraction of events

I also looked at a couple of events that are "ghosty" according to this algorithm:
they look like perfect gamma-ray in which also the old reconstruction works fine

Evt Id 130047	Evt Id 333286

8 tagged xtals 80% ghost-energy	32 tagged xtals 97% ghost-energy

In conclusion, this algorithm cannot be applied to flight data.

Ghost number and cluster classification

tbd

Event display

AG v19r4p1gr13 with OVL	AG v19r4p1gr13 with OVL

blue is the 1st cluster, is a ghost and has a ghost number of 3, red is the 2nd (gamma) cluster that corresponds to the gamma track	blue is the 1st cluster and is the good gamma, red is the 2nd cluster and is a ghost with a ghost number of 2, note that the corresponding tkr hits aren't tagged as ghost hits

Confluence and Jira now require federated login. Read more.

Space shortcuts

Blog

Summary

Information available

Analysis

Code and method

Overlay energy for tagged clusters (MonteCarlo AG)

Efficiency with Periodic Triggers

Effect on Flight Data

Ghost number and cluster classification

Event display

Reason for change

Test Procedure

Rollback procedure

CCB Jira

Details

Complete set of tags for L1Proc 3.3

Reason for change

Test Procedure

Rollback procedure

CCB Jira

Details

Complete set of tags for L1Proc 3.2