- Filtering procedure
- Filtering tasks: implementation
- Calibration tasks: implementation
- Code and Examples
The calibration train is aimed at filtering the ESD friends and produce offline calibration objects at the same time. The output of the calibration train is the AliESDfriends_v1.root file, where both the tree of the filtered ESD friends and the calibration object extracted chunk by chunk will be stored.
The filtering procedure includes two main components:
- Steering filter
- Detector-specific filters
The filters may both select at event level, and, once an event has been selected, at track level.
The steering filter is meant to keep all the friend tracks for only 1% of the whole sample of events. The selection is performed randomly.
The detector-specific filters are aimed to select, on top of the events already selected by the steering filter, some other events that are consider of some interest (e.g. events containing high-pT tracks).
Each filter - both at event level and and track level - work in a logic OR with respect to the others. In other words, each event/track is kept provided that at least one task selected it.
Each filtering task should derive from AliAnalysisTaskFilter (which, in its turn, derives from AliAnalysisTask). Any new filter task should then implement the following methods:
- UserSelectESDfriendForCurrentEvent: called at every event, defines the criteria according to which the event is selected or not by the current task;
- UserExec: called only when the event is selected (see previous method), defines for which tracks the friends will be kept, and for which the will be discarded. According to the action to be taken, one of the two following methods should be called:
- AddFriendTrackAt(AliESDfriendTrack* t, Int_t index): to be called in case the friend has been selected to be kept. The friend track t (copied from the input) will be stored in the output at position index;
- SkipFriendTrackAt(Int_t index): position index in the friend tracks TClonesArray of the output will be filled with a "dummy" friend track (provided that no other task has already called the AddFriendTrackAt() method for the current track)
Each filtering task can access the ESD event and the ESD friend via the methods AliAnalysisTaskFilter::InputEvent() and AliAnalysisTaskFilter::InputFriend().
Each detector-specific filtering task should follow the naming convention: AliAnalysisTaskFilterDET, where DET is the offline name of the detector. Moreover, it should be put in the detector module in AliRoot. One steering macro (AddTaskFilterDET.C) is foreseen per detector.
The calibration tasks should be standard tasks (inheriting from AliAnalysisTask), for which the output file should be AliESDfriends_v1.root.
There is ongoing work in order to have the possibility to have tasks deriving from AliAnalysisTaskSE included in the framework.
Even if more than one calibration tasks can be there per detector, only one steering macro (AddTaskDETCalib.C) is allowed. Each detector-specific calibration task should be put in the detector module in AliRoot, together with the steering macro.
The code is present in AliRoot in the ANALYSIS module. Here, the base class (AliAnalysisTaskFilter), the steering filtering class (AliAnalysisTaskFilterSteer), and some examples (AliAnalysisTaskFilterFriend - keeping only the events with an even number of tracks, and of these, keeping every second track - and AliAnalysisTaskFilterFriendSecond - keeping all the events, and for these every third track) can be found.
The steering macro for the central filtering task (AddTaskFilterSteer.C) can be found in $ALICE_ROOT/ANALYSIS/CalibMacros.
Analogously, in $ALICE_ROOT/ANALYSIS you can find an example of task (AliAnalysisTaskAddObject) which reads the ESDs and the friends, and fills a histogram (with the integrated length) to be then stored in the AliESDfriends_v1.root file. The configuration macro is again in $ALICE_ROOT/ANALYSIS/CalibMacros.