]>
Commit | Line | Data |
---|---|---|
1 | // $Id$ | |
2 | ||
3 | /*! \page README_sim Simulation | |
4 | ||
5 | The simulation encompasses the following tasks : | |
6 | ||
7 | - Generation of MC particles (the kinematics of the event ends up in the TreeK | |
8 | of Kinematics#.root) | |
9 | ||
10 | - Tracking particles through the detector using | |
11 | the Virtual Monte Carlo, producing AliMUONHit objects, that end up in | |
12 | the TreeH of MUON.Hits#.root file(s). This part is steered by AliMUON and its child | |
13 | AliMUONv1 classes. | |
14 | ||
15 | - Converting MC hits into AliMUONVDigit, called SDigits, that end up in the TreeS | |
16 | of the MUON.SDigits#.root file(s). A S(ummable)Digit is a pad with its associated | |
17 | charge, but no noise or electronics response function applied. Steered by AliMUONSDigitizerV2 class. | |
18 | ||
19 | - Converting SDigits into Digits, by applying electronics calibrations. Actually, we de-calibrate | |
20 | the digits at this stage, by adding a pedestal and dividing by a gain, more or less. Steered | |
21 | by AliMUONDigitizerV3 class. Digits end up in TreeD of MUON.Digits#.root file(s). In addition, | |
22 | for the trigger, we create AliMUONLocalTrigger, AliMUONRegionalTrigger and AliMUONGlobalTrigger objects | |
23 | at this stage, that ends up in TreeD as well. | |
24 | ||
25 | - Convert the Digits into RAW data, in a format that should be exactly the same as real data from the | |
26 | DAQ. Performed by AliMUONRawWriter. | |
27 | ||
28 | From there on, the reconstruction can proceed, in the very same way for real or simulated data, | |
29 | as long as they are in RAW format. | |
30 | ||
31 | \section sim_s1 How to run a MUON generation | |
32 | ||
33 | You only need to run the simulation part of the test script | |
34 | AlirootRun_MUONtest.sh | |
35 | ||
36 | ||
37 | \section sim_s2 Tracking parameters, cuts, energy loss and physics processes | |
38 | ||
39 | Tracking parameters in MUON are automatically defined by GEANT | |
40 | MUON takes the default values of CUTs and physics processes | |
41 | defined by the Config files, except for the gas mixture medium | |
42 | of the tracking chambers. The CUT's and physics processes of | |
43 | the gas mixture medium is then defined in the galice.cuts file | |
44 | in the data directory. In particular ILOSS parameter MUST be | |
45 | equal unity (1) in order simulate a realistic energy loss | |
46 | distribution (mean value and fluctuations) in the active gas. | |
47 | ||
48 | \section sim_s3 Tracking of particle in the magnetic field | |
49 | ||
50 | GEANT has two integration methods for tracking charged particles in the | |
51 | magnetic field: HELIX et RKUTA. | |
52 | HELIX is faster and works well if the gradient of magnetic | |
53 | field is small. | |
54 | For MUON, HELIX is a not a good approximation and we must | |
55 | use RKUTA to get the optimal mass resolution of the | |
56 | spectrometer. The choice of HELIX or RKUTA is done in the | |
57 | config file when the magnetic field is defined: | |
58 | <pre> | |
59 | TGeoGlobalMagField::Instance() | |
60 | ->SetField(new AliMagF("Maps","Maps", INTEG, FACTOR_SOL, FACTOR_DIP, MAXB, AliMagF::k5kG)); | |
61 | </pre> | |
62 | INTEG must be 1 for RKUTA and 2 for HELIX (the default value for aliroot is 2 (HELIX)). | |
63 | FACTOR_SOL, FACTOR_DIP allow you to set the multiplicative factor for solenoid | |
64 | and dipole, respectively; just putting FACTOR_SOL=0 or FACTOR_DIP=0 will set the | |
65 | magnetic field for solenoid or dipole to 0. Default values are 1.0, 1.0. | |
66 | MAXB is the maximum magnetic field which default value is 10.T | |
67 | ||
68 | \section sim_s4 Tailing effect | |
69 | ||
70 | The control to turn on/off the parametrized tailing effect: | |
71 | <pre> | |
72 | AliMUON::SetTailEffect(Bool_t), | |
73 | </pre> | |
74 | ||
75 | The parameter to tune increase/decrease the tailing effect is kept inside, | |
76 | AliMUONResponseV0::DisIntegrate(). This parameter is an integer number | |
77 | (excluding zero and four), the higher the value is the less is the tailing | |
78 | effect: | |
79 | <pre> | |
80 | Int_t para = 5; | |
81 | </pre> | |
82 | Zero is excluded because it gives straight line transformation, and four | |
83 | is excluded because the AliRoot simulation chain spends VERY VERY long | |
84 | time in AliMUONResponseV0::DisIntegrate method, which reason was not yet | |
85 | understood. The parameter for 1, 2, 3, 5, 6, 7, 8, 9, 10 were checked with | |
86 | no slowing down problem, however parameters greater than 6 give almost no | |
87 | tailing effect since they basically correspond to higher order polynomial | |
88 | transform. | |
89 | ||
90 | ||
91 | \section sim_s5 MUON cocktail generator | |
92 | ||
93 | There is a MUON cocktail generator of the muon sources in the | |
94 | EVGEN directory. This class derives from AliGenCocktail. | |
95 | In the init of this class I have filled the cocktail with | |
96 | the muon sources: J/Psi, Upsilon, Open Charm, Open Beauty, | |
97 | Pion, Kaons. The code needs only the production cross section | |
98 | at 4pi (for the moment this values are in the code since I | |
99 | prefere them do not be modified), and the code calculates the | |
100 | rate of particles in the acceptance, making the scaling based | |
101 | on the number of collisions for the hard probes and on the | |
102 | number of participants for soft sources: Pions and Kaons. | |
103 | ||
104 | In the Genereate of this class all entries in the cocktail | |
105 | are called and we define a "primordial trigger" with requires | |
106 | a minimum number of muons above a Pt cut in the required acceptance. | |
107 | In order to normalized to the real number of simulated events, | |
108 | there are 2 data members in the class fNsuceeded adn fNGenerate | |
109 | which tell us what is the biais source. | |
110 | ||
111 | Enclose an example to use this generator: | |
112 | <pre> | |
113 | AliGenMUONCocktail * gener = new AliGenMUONCocktail(); | |
114 | gener->SetPtRange(1.,100.); // Transverse momentum range | |
115 | gener->SetPhiRange(0.,360.); // Azimuthal angle range | |
116 | gener->SetYRange(-4.0,-2.4); | |
117 | gener->SetMuonPtCut(1.); | |
118 | gener->SetMuonThetaCut(171.,178.); | |
119 | gener->SetMuonMultiplicity(2); | |
120 | gener->SetImpactParameterRange(0.,5.); // 10% most centra PbPb collisions | |
121 | gener->SetVertexSmear(kPerTrack); | |
122 | gener->SetOrigin(0,0,0); // Vertex position | |
123 | gener->SetSigma(0,0,0.0); // Sigma in (X,Y,Z) (cm) on IP position | |
124 | gener->Init(); | |
125 | </pre> | |
126 | ||
127 | \section sim_s6 How to simulate events with misaligned geometry in local CDB | |
128 | ||
129 | If you want to use a misaligned geometry to simulate some | |
130 | events you can use a local CDB. For this need to follow | |
131 | the next steps: | |
132 | ||
133 | - Generate misaligned data in local CDB. | |
134 | You can use MUONGenerateGeometryData.C as described above in | |
135 | the corresponding section. Let's assume you used the default | |
136 | residual misalignment settings, then you have a local CDB in | |
137 | your working directory called ResMisAlignCDB containing | |
138 | misalignement data (ResMisAlignCDB/MUON/Align). | |
139 | ||
140 | - Tell AliSimulation you want to use your local CDB for | |
141 | MUON/Align/Data | |
142 | To do this you need to instantiate the AliCDBManager, set the | |
143 | default storage and set the specific storage for MUON/Align/Data, | |
144 | before instantiating AliSimulation (see for example the commented | |
145 | lines AlirootRun_MUONtest.sh). | |
146 | ||
147 | <pre> | |
148 | aliroot -b >& testSim.out << EOF | |
149 | AliCDBManager* man = AliCDBManager::Instance(); | |
150 | man->SetDefaultStorage("local://$ALICE_ROOT/OCDB"); | |
151 | man->SetSpecificStorage("MUON/align/Data","local://ResMisAlignCDB"); | |
152 | AliSimulation MuonSim("$ALICE_ROOT/MUON/Config.C"); | |
153 | MuonSim.SetWriteRawData("MUON"); | |
154 | MuonSim.Run(10); | |
155 | .q | |
156 | EOF | |
157 | </pre> | |
158 | ||
159 | \section sim_s7 How to Merge events | |
160 | ||
161 | You can merge 2 types of simulated events. For example, | |
162 | you can simulate Hijing events, and then simulate muons | |
163 | merging both. | |
164 | ||
165 | Merging is done at the sdigits level, so Kinematics files | |
166 | of the merged events will just correspond to the | |
167 | Config.C simulated file). | |
168 | ||
169 | You must, first, do the Hijing simulation and store it | |
170 | in directory $HIJING_SIM. Note that for merging you | |
171 | won't need Kinematics files of the Hijing simulation... | |
172 | ||
173 | Hijing simulation | |
174 | ||
175 | <pre> | |
176 | aliroot -b << EOF | |
177 | AliSimulation HijingSim("$HIJING_SIM/YourConfigForHIJING.C") | |
178 | HijingSim.Run(5) | |
179 | .q | |
180 | EOF | |
181 | </pre> | |
182 | ||
183 | You cand build YourConfigFroHIJING.C File from the | |
184 | ConfigPPR file in AliRoot/macros module. | |
185 | ||
186 | Then you can do muon simulation and reconstruction | |
187 | merging both simulated events. In next example, we are | |
188 | merging 20 times each Hijing event in order to simulate | |
189 | 100 muons merged with 5 Hijing events. | |
190 | ||
191 | <pre> | |
192 | aliroot -b << EOF | |
193 | AliSimulation MuonSim("$ALICE_ROOT/MUON/Config.C") | |
194 | MuonSim.MergeWith("$HIJING_SIM/galice.root",20) //parameters are the Hijing simulation file and the number of times we use each Hijing event | |
195 | MuonSim.Run(100) // number of muon (Config.C) events | |
196 | .q | |
197 | EOF | |
198 | ||
199 | ||
200 | aliroot -b << EOF | |
201 | TPluginManager * pluginmanager = gROOT->GetPluginManager() | |
202 | pluginmanager->AddHandler("AliReconstructor","MUON","AliMUONReconstructor","MUON","AliMUONReconstructor()") | |
203 | AliReconstruction MuonRec("galice.root") | |
204 | MuonRec.SetRunTracking("") | |
205 | MuonRec.SetRunVertexFinder(kFALSE) | |
206 | MuonRec.SetRunLocalReconstruction("MUON") | |
207 | MuonRec.SetFillESD("MUON") | |
208 | MuonRec.Run() | |
209 | .q | |
210 | EOF | |
211 | </pre> | |
212 | ||
213 | \section sim_s8 On track numbering | |
214 | ||
215 | All generated particles, including primary and secondary | |
216 | particles are put on the stack. The secondary particles are kept | |
217 | in the stack only if they gave a hit in *any* of the ALICE detectors | |
218 | The number of all particles placed on the stack for a given event | |
219 | can be obtained with | |
220 | Int_t nPart = AliStack::GetNtrack(); | |
221 | Looping from 0 to nPart via AliStack::Particle(ipart) | |
222 | gives the particle listing as obtained from the particle generator (primaries) | |
223 | and Monte Carlo (secondaries). | |
224 | ||
225 | The particle response in the detector, a hit, is registered | |
226 | in the hits tree and the hits are filled with each primary track. | |
227 | The total number of "tracks" (fills of the tree) can be obtained | |
228 | with ntracks = AliMUONMCDataInterface::NumberOfTracks(event) and is usually smaller than "nPart". | |
229 | Since particles can also deposit hits in other detectors than | |
230 | the MUON spectrometer, there will be many "tracks" (fills) in the hit-tree | |
231 | without a hit in MUON. | |
232 | ||
233 | The correspondence between "track ID" in the hits-tree ("itr") and the | |
234 | particle ID for particles on the stack (i.e. generated particles) can be | |
235 | obtained via: | |
236 | <pre> | |
237 | for (Int_t itr = 0; itr < ntracks; itr++) { | |
238 | AliMUONVHitStore* hitStore = mcDataInterface.HitStore(event,itr); | |
239 | //track "itr" of the hits-tree | |
240 | Int_t nhitstot = hitStore->GetSize(); | |
241 | AliMUONHit* mHit; | |
242 | TIter next(hitStore->CreateIterator()); | |
243 | while ( ( mHit = static_cast<AliMUONHit*>(next()) ) ) | |
244 | { | |
245 | Int_t id = mHit->Track(); //gives particle ID on stack | |
246 | TParticle* particle = mcDataInterface.Stack(event)->Particle(id); | |
247 | } | |
248 | } | |
249 | </pre> | |
250 | ||
251 | where mcDataInterface has been obtained by | |
252 | AliMUONMCDataInterface mcDataInterface("galice.root"); | |
253 | ||
254 | During the procedure to go from hits to digits, the hits | |
255 | are summed up such that more than one track can contribute | |
256 | to a given digit. As a consequence the method | |
257 | Int_t AliMUONDigit::Track(Int_t trackID) | |
258 | takes an argument, where "trackID" runs from 0 to | |
259 | AliMUONDigit::Ntracks() to provide the reference to *all* | |
260 | tracks that contributed to it. The returned track ID is the one | |
261 | referred to in the hit-tree. To know which is the generated particle | |
262 | that deposited a given digit one has to follow the sequence of the kind: | |
263 | (shown here using the simple, but not fast, DataInterface interfaces) : | |
264 | ||
265 | <pre> | |
266 | AliMUONMCDataInterface mcdi("galice.root"); | |
267 | AliMUONDataInterface di("galice.root"); | |
268 | ||
269 | AliMUONVDigitStore* digitStore = di.DigitStore(event); | |
270 | AliMUONVDigit* mDigit = ... get some digit from the digitStore | |
271 | ||
272 | for (int tr = 0; tr < mDigit->Ntracks(); tr++) | |
273 | { | |
274 | Int_t hitTrackID = mDigit->Track(tr); | |
275 | // get the hits corresponding to this trackID | |
276 | AliMUONHitStore* hitStore = mcdi.HitStore(event,hitTrackID); | |
277 | // loop over the hits | |
278 | TIter hNext(hitStore->CreateIterator()); | |
279 | AliMUONHit* mHit; | |
280 | while ( ( mHit = static_cast<AliMUONHit*>(hNext()) ) ) | |
281 | { | |
282 | Int_t numPart = mHit->Track(); //gives ID of particle on the stack | |
283 | Int_t idTrack = mHit->Particle(); //gives flavour code of the particle | |
284 | } | |
285 | } | |
286 | </pre> | |
287 | ||
288 | This chapter is defined in the READMEsim.txt file. | |
289 | ||
290 | */ |