1. Gustavo Conesa Balbastre
EMCal Offline Status
Gustavo Conesa Balbastre
15/03/2010
EMCal Status

2. EMCAL status @ Point 2 4 Super Modules installed
2 SM in C side, installed in March
2 SM in A side, installed in July
Took data successfully in 2009 runs.
But offline results are …
Triggers under commissioning.
Bad channels
For Pass 5 of 900 pp data there where 42 (of 4608) bad channels:
SM 0, n dead/hot 3;
SM 1, n dead/hot 16;
SM 2, n dead/hot 12: Bad FEE
SM 3, n dead/hot 11
For 2010 runs, some bad channels recovered (still not in OCDB)
Dead 6, Noisy 10.
15/03/2010
EMCal Status

3. Pi0 invariant mass peak … combine all SuperModules
Pass 2
Nice peak at … 100 MeV instead of 135 MeV
The only good news … it seems that relative calibration is rather good, quite narrow peak.
15/03/2010
EMCal Status

4. Pi0 invariant mass peak … per SuperModule
Same thing observed for all SuperModules, there is a peak but at 100 MeV.
15/03/2010
EMCal Status

5. What is the problem?
Many can be the sources, and their combination could explain it:
Raw fitting,
We might have been underestimating the energy in the fit?
Tiny improvement with last modifications has been observed.
Absolute calibration
Relative calibration seems rather good.
Cosmic MIP peak is close to the right place, so not clear it is a problem.
ZS threshold too high (3 ADC counts).
Alignment correction
Survey shows a 3 cm shift of SuperModules. Not corrected yet.
Non linearity correction.
We are dealing with really low energy clusters, where the non linearity is more important up to 20%. No correction done until now.
Geometry not well implemented?
The mapping problem has no effect, apparently.
No big changes from pass2 to pass 5 where this was corrected.
Need complete revision.
Other issues to be found out?
15/03/2010
EMCal Status

6. Mapping ALICE conventions
Increase tower index in phi implies increase of phi angle
Increase tower index in eta implies decrease of eta
Hardware mapping follows these conventions but not offline that followed the GEANT indexing:
C side : eta wrong
A side: phi wrong
Fixed in trunk and release :
AliEMCALGeometry::RelPosCellInSModule() : Methods where indexes and global positions are translated.
AliEMCALv2::StepManager(): Assign to the hits not the indexing given by GEANT but the corrected one.
PROBLEM: Backward incompatibility when checking the labels of the towers. Old simulation ESDs cluster position will be ok, but reanalysis on these ESDs taking into account the cell index (Jet?) will not be correct if last aliroot is used.
15/03/2010
EMCal Status

7. Raw fitting A lot of development has been done the last months.
Persons involved
David Silvermyr: Task coordinator and benchmarking.
Per Thomas Hille:
Development of frame to handle different fitters.
Peak finder fitter implementation.
Paola La Roca: Neural Network fitter.
Alexei Pavlinov: Fast Fitter.
Main goal, develop a fast fitter, that can be used either in offline and HLT with good performance.
Fitters currently in the code:
Slow fitters (truth for benchmarking comparisons):
kStandard: default fitter used until now, Minuit fit, too slow.
kLMS: refined version of kStandard
Fast Fitters
kFastFit
kNeuralNet
kPeakFinder
kCrude: Takes the maximum bin.
15/03/2010
EMCal Status

8. Raw fitting: Spread/Mean
We compare the ouput of the different fitters for one channel, high gain.
LED runs are used.
Since this plot was done tuning of Neural Net and Peak finder have improved.
Decision still not taken, need to do further tests with pp data.
15/03/2010
EMCal Status

9. Raw fitting: Time resolution
One remaining task was the implementation of realistic time resolution in simulation.
With the current benchmarking we are close to finish this task.
Difference between the maximum time bin of 2 close towers, versus tower amplitude.
15/03/2010
EMCal Status

10. Time measurement
Very different value of the tower time measured in simulation and data.
Simulation-LHC09d10
Data - Pass 5
15/03/2010
EMCal Status

11. Track Matching Pass 2: not matches at all due to mapping problem.
We have a low track matching probability in real data.
Still mapping issues, wrong geometry?
Pass5
Simulation
LHC09d10
15/03/2010
EMCal Status

12. Track matching in cosmic data
All Clusters - All Tracks in the event.
Strange structure at Z.
Do we have still mapping issues?
15/03/2010
EMCal Status

13. Track Matching We tried to check the matching via 2 different methods:
(AliExternalTrackParam*)track->GetOuterParam()->GetXYZAt(radius,bfield,Pos) (
Method 2
AliEMCALTracker::FindExtrapolationPoint(Double_t x,Double_t y, Double_t z, AliESDtrack *track)
Tested them with cosmic data, with and without field.
15/03/2010
EMCal Status

14. Track Matching Cosmic Run, Field On, Method 1
With method 2 looks better
15/03/2010
EMCal Status

15. Track Matching
Cosmic runs, Z of cluster - Z of track (zoom of previous plot)
15/03/2010
EMCal Status

16. Calibration Pass 5 cell energy plots.
SM 1 seems to have a 20% difference in the cells energy. Miscalibration that is being corrected.
The rest of the SM look similarly performing.
New calibration DB soon available.
15/03/2010
EMCal Status

17. Calibration: MIP Pass5 cosmic
MIP peak should be at 260 MeV, value used in the calibration with cosmics at Grenoble.
Not really observed in collisions data but in cosmics, where it is cleaner and tracks have higher momentum. It is lower than expected, we suspect ZS cut is too large.
cosmic
E (GeV)
15/03/2010
EMCal Status

18. Trigger New trigger code in place. New classes
Better emulation of the trigger performance.
Old AliEMCALTrigger still kept since called by the actual offline trigger frame and during EMCAL ESD filling.
New classes
AliEMCalTriggerElectronics, manager class: Replace for AliEMCALTrigger
Creates the TRU and STU objects.
Run during reconstruction
AliEMCALTriggerBoard, defines trigger subregions, deriving
AliEMCALTriggerTRU and AliEMCALTriggerSTU
AliEMCALTriggerPatch (x, y, sum): performs the patch
AliEMCALTriggerData: contains triggering data to be stored in the RecPoint tree for post processing.
AliEMCALTriggerSTURawStream: STU Raw Data decoder
AliEMCALRawDigit: FALTRO or ALTRO time sample container.
15/03/2010
EMCal Status

19. Trigger
Problem: Need to access information from VZERO, like in the real life.
The actual implementation has shown some problems:
VZERO Digits information accessed during EMCAL reconstruction
first inter-detector dependence in AliRoot.
Cvetan et al. not very pleased with the way it is done ;-)
Since VZERO is reconstructed after EMCAL, in raw reconstruction we are doing nothing with the VZERO digits.
Any suggestion on how to do it otherwise is welcome.
For running the online monitoring it is necessary to load the libVZERObase.
Other issues with ESD VZERO (Mateusz):
ADC value is stored in Short_t and I believe in the HI case the max value goes over the range and the bit is flipped on short producing (very disturbing) negative ADC values within VZERO digits.
Is this being followed up/solved?
15/03/2010
EMCal Status

20. Proposed redefinition of digit
A digit right now is an amplitude and time per channel obtained after digitization of the energy lost in simulation or fit of the raw time sample.
This approach does not take into account is simulation:
Fitting problems
Samples with different time arrival, pile-up.
Rachid needed for the trigger emulation to get from the digit the FALTRO time sample and implemented a new object called AliEMCALRawDigit: Time Sample for a given tower.
Suggested approach by Rachid:
Merge AliEMCALRawDigit into AliEMCALDigit so that we will have in a digit the amplitude, time and the time sample.
In simulation, the amplitude and time are calculated from the fitting of the time sample with the same fitter used with data.
The time sample is calculated from the SDigit energy.
When doing merging, add the time samples and fit the resulting sample.
In order to have a realistic performance, we need to implement a more realistic shaper (energy to time sample).
What we have right now in DigitsToRaw does not produce a realistic pulse.
Need volunteer to work on this.
15/03/2010
EMCal Status

21. HLT - EMCal Offline HLT and offline should produce same results.
Task force in place and managed by Mateusz Ploskon.
We need to factorize the code that can be used in both Offline and HLT:
Raw fitting: First attempts already in place (EMCAL/AliCaloRawAnalyzer)
Clusterization:
Cluster finding
Cluster unfolding …
Trigger
Geometry?
… and it must be fast.
If possible, EMCAL and PHOS could use sometimes the same code.
Need to create a new CALO module under $ALICE_ROOT
The same fitters could be used by PHOS and EMCAL and even clusterizers(???)
15/03/2010
EMCal Status

22. Geometry tasks Task 1319: Geometry as installed: Finally done.
EMCAL_FIRSTYEAR: 4 SM: 80º <  < 120º, -0.7 <  < 0.7
EMCAL_COMPLETE: 12 SM: 80º <  < 190º, -0.7 <  < 0.7
Alignment macros and different config files updated.
Task 2533: Finalization of the detector geometry checking for overlaps.
Detector geometry implemented is ideal, no overlaps in this case.
Space frame implementation is OK.
We got finally the survey data. Now we are in the process to translate it and put it in the OCDB and perform the checks.
After the data results, we are trying to do a full revision of the geometry to try to find more bugs.
15/03/2010
EMCal Status

23. Simulation tasks
Task 2538: Correct treatment of detector signal in sdigits correct event merging implementation
Discussed previously.
Task 2537: Verification of event merging procedures
Event merging with the actual definition of Digits works. Need to redo after new implementation.
Task 2534: Handling of the time information from hits during digitization
Not clear how the raw to digit time is calculated, very different results in simulation and real data. Under investigation.
Task 2535: Implement realistic time resolution in digits.
In the code now we have a fixed time resolution of 0.6 ns
We have to implement a resolution depending on the amplitude. Investigation in parallel with raw fitting benchmarking.
15/03/2010
EMCal Status

24. Simulation tasks Task 2627 : Correct detector response.
GEANT simulations and beam test show a few % discrepancy.
A correction approach defined: Correct at the digit level, knowing the resolution measured in simulation and beam test.
Need to find a simple correction function.
FLUKA simulations showed unexpected bigger reconstructed energy than generated. What about GEANT4?
Ivana found that cuts for GEANT4 and FLUKA were default, not same cuts as for GEANT3, maybe this cures discrepancy with FLUKA, not checked.
Eva has compared GEANT3 and GEANT4, there are differences.
In order to correct any difference, we will have to use a different sampling fraction: Need a way to know which MC was used.
Fluka vs Geant3
Old, maybe now it looks better.
E=10 GeV
Preliminary, need to understand why she gets Geant3 peak displaced
15/03/2010
EMCal Status
Egen-Erec (GeV)

25. Trigger tasks Task 2628 : Update trigger simulation tasks
Done.
Task 2549: Testing of trigger simulation with raw data
Done, it performs as in simulations.
Task 2548: Implementation of the code for trigger parameters for the simulation of the trigger input to the CTP.
Need to understand this task.
15/03/2010
EMCal Status

26. Reconstruction tasks Task 2632: Track matching improvement
Low electron matching efficiency found in grid productions and real data.
Task 2633: Cluster unfolding implementation for !=0
Implemented the “simple” case  = 0
Common task with HLT, Berkeley group interested in this task.
Tasks 2630 : Study effect of misalignment in reconstruction.
Depend on geometry task 2533
15/03/2010
EMCal Status

27. QA
Person in charge Raw QA: David, Francesco and Yaxian. Rest of QA, Yaxian.
Task 2551 and 2554: Implementation of run type and reference data
Need to produce data to generate reference histograms, p+p and Pb+Pb data available on the grid.
Task 2642: Extract QA data from MC production:
To be done in the next days from recent production. Only LowMultiplicity case.
QA analysis class developed: PWG4/PartCorrDep/AliAnaCalorimeterQA
It should run in the QA train and it runs regularly in the PWG4 mini train.
Some of the plots from pass 5 done with it.
15/03/2010
EMCal Status

28. HLT Status: Reconstruction chain
15/03/2010
EMCal Status

29. HLT: To Do list
15/03/2010
EMCal Status

30. Online
Online Task 1455 (2329,2546): Time dependence online calibration interface
For 2009 runs, temperature in pit was stable and calibration does not change..
Nothing to be done for the moment, need to check for long data taking periods this year.
We have two DA's:
1) LED amplitude vs Time (EMCALLEDda, AliCaloCalibSignal)
2) DeadMaps + pedestal info [for ZS, online] (EMCALPEDda, AliCaloCalibPedestal).
In production at P2 since September, at the moment only for standalone runs. We plan to activate 1) also for physics
15/03/2010
EMCal Status

31. Documentation
Due to the increasing number of people now at last interested in the EMCAL offline results, we need to create some documentation.
Place for the documentation in
A document for beginners also available
Still a lot of things to complete.
It also includes a section with the ESD/AOD information stored for the calorimeters.
15/03/2010
EMCal Status

32. ESDs Should we clean up some old unused methods/data members?
AliESDCaloCluster:
TArrayS * GetDigitAmplitude();  TArrayS * GetDigitTime(); TArrayS * GetDigitIndex(); Int_t GetNumberOfDigits()
AliESDEvent:
Int_t GetNumberOfEMCALClusters(); Int_t GetFirstEMCALCluster(); Int_t GetNumberOfPHOSClusters(); Int_t GetFirstPHOSCluster()
This could cause backward incompatibility when reading very very old data,but not data generated during last year.     
15/03/2010
EMCal Status

33. Backup
15/03/2010
EMCal Status

34. TClonesArray in Loader
Issue not forgotten.
Federico discovered that AliEMCALLoader owns several TClonesArrays.
a loader is not supposed to own just to load.
// All data are stored in TTrees on file.
// These TCLonesArrays are temporary storage for reading or writing // (connected to TTrees with SetBranchAddress)
TClonesArray *fHits; //! TClonesArray of hits (for tree reading)
TClonesArray *fDigits; //! TClonesArray of digits (for tree reading)
TClonesArray *fSDigits;//! TClonesArray of sdigits (for tree reading)
TObjArray *fRecPoints;//! TClonesArray of recpoints (for tree reading)
Small effect in the memory consumption, but must be avoided.
Current version developed 4 years ago by Marco, problematic to get it work at this time.
15/03/2010
EMCal Status

35. Tests with new fitters on data
kLMS and kPeakFinder, similar energy but different trend compared to pass 5 (maybe some event scaling problem I have not understood), more clusters/digits close to threshold energy.
Problems in kNeuralNet and kFastFit due to some default big amplitude, corrected in trunk.
Time wrong for new fitters, corrected in trunk.
15/03/2010
EMCal Status

36. Tests with new fitters on data
kLMS
15/03/2010
EMCal Status

37. Tests with new fitters on data
Mass a bit higher …
kLMS
Pass 5
kPeakFinder
15/03/2010
EMCal Status