1 | ------------------------------------------------------------------- |
---|
2 | $Id: README,v 1.12 2006/07/25 11:02:56 gcosmo Exp $ |
---|
3 | ------------------------------------------------------------------- |
---|
4 | |
---|
5 | ========================================================= |
---|
6 | Geant4 - Composite calorimeter example |
---|
7 | ========================================================= |
---|
8 | |
---|
9 | README |
---|
10 | --------------------- |
---|
11 | |
---|
12 | CompositeCalorimeter is an example of a test-beam simulation used |
---|
13 | by the CMS Collaboration to validate Geant4 against real data taken |
---|
14 | (in 1996) in a CMS Hadron calorimeter test-beam. |
---|
15 | The name "Composite" for this example emphasizes that, although the |
---|
16 | test-beam had the goal of studying the hadronic calorimeter response, |
---|
17 | part of the data was taken with the presence of the electromagnetic |
---|
18 | crystal calorimeter in front of the hadronic calorimeter, to better |
---|
19 | reproduce the situation as in the real CMS experiment. |
---|
20 | The geometry of the simulation has been setup in such a way to allow |
---|
21 | very easily, at run time (therefore without need of changing any code; |
---|
22 | see below for the details) the inclusion or exclusion of the |
---|
23 | electromagnetic calorimeter part. |
---|
24 | Although some important aspects, for a detailed comparison between |
---|
25 | test-beam data and simulation, like beam profile, noise, and digitization, |
---|
26 | have been omitted here (to avoid too many technical details), |
---|
27 | nevertheless, this example is able to reproduce the main features of |
---|
28 | most of the relevant observables as measured in the real test-beam. |
---|
29 | The output of this example, if the AIDA or Anaphe/Lizard environment |
---|
30 | has been properly setup (see below), consists of a set of histograms |
---|
31 | and one ntuple which are stored on a HBOOK file. |
---|
32 | In our opinion, the most original "lesson" which is offered by this |
---|
33 | advanced example for the Geant4 user is to show how the Geometry and |
---|
34 | the Sensitive/Hit part of the simulation is treated in a big experiment. |
---|
35 | Although the details of how this is done vary from experiment to |
---|
36 | experiment (it is worth, for instance, to compare with the Atlas-based |
---|
37 | advanced example lAr_calorimeter), the main driving needs and goals |
---|
38 | are quite general: to have consistency, but avoiding duplications |
---|
39 | and couplings as much as possibile, between Simulation, Reconstruction, |
---|
40 | and Visualization. Notice that the solution offered in this example |
---|
41 | by CMS could appear "overdone" for the sake of simulating only a |
---|
42 | relatively simple test-beam setup; but it should be kept in mind |
---|
43 | that the same approach is used also for the full CMS detector |
---|
44 | simulation, as well as for any subdetector. |
---|
45 | |
---|
46 | |
---|
47 | 1. Setting up the environment variables |
---|
48 | --------------------------------------- |
---|
49 | |
---|
50 | The user should first setup, as "usual", the Geant4 environmental |
---|
51 | variables (in particular, the variable G4ANALYSIS_USE must be set |
---|
52 | if you want to have the histograms and the ntuple). |
---|
53 | Then the specific setup for this example, including the AIDA/PI part |
---|
54 | used in the analysis, should be run: |
---|
55 | |
---|
56 | > source envExample.csh in the case of C-shell |
---|
57 | or |
---|
58 | > . envExample.sh in the case of bash-shell |
---|
59 | |
---|
60 | The analysis part is based on AIDA/PI. |
---|
61 | Please take a look to the web page: http://www.cern.ch/PI . |
---|
62 | |
---|
63 | |
---|
64 | 2. Sample run |
---|
65 | ------------- |
---|
66 | |
---|
67 | Once the environmental variables are setup, you can get the executable |
---|
68 | $G4WORKDIR/bin/$G4SYSTEM/CompositeCalorimeter |
---|
69 | by typing "gmake" on this directory. |
---|
70 | Then, you can execute it using the Geant4 macro command input file test.g4mac |
---|
71 | as follows: |
---|
72 | |
---|
73 | > $G4WORKDIR/bin/$G4SYSTEM/CompositeCalorimeter test.g4mac |
---|
74 | |
---|
75 | which simulate 10 events, each being a 100 GeV pi- incident on the |
---|
76 | electromagnetic crystal calorimeter followed by the hadronic calorimeter, |
---|
77 | without magnetic field. |
---|
78 | The output is the HBOOK file "ccal.his" , which can be seen either with |
---|
79 | Lizard (or any other AIDA-compliant package) or with Paw or Root. |
---|
80 | See part "8. Analysis / Histogramming" below for more details on the |
---|
81 | content of that file. |
---|
82 | If you run instead: |
---|
83 | |
---|
84 | > $G4WORKDIR/bin/$G4SYSTEM/CompositeCalorimeter |
---|
85 | |
---|
86 | after having setup the Geant4 visualization variables and the PATH, |
---|
87 | you can visualize the geometry of the apparatus, and also see some |
---|
88 | events. Similarly, you can get a very simple graphical user interface |
---|
89 | that allows to select the particle type, its energy, and the number |
---|
90 | of events (between a limited number of possibilities). |
---|
91 | For more details, see part "9. Visualization / GUI". |
---|
92 | |
---|
93 | |
---|
94 | 3. Detector description |
---|
95 | ----------------------- |
---|
96 | |
---|
97 | Let's start with a brief description of the test-beam setup. |
---|
98 | |
---|
99 | There are two possible configurations: |
---|
100 | i) HCAL only, that is only the hadronic calorimeter is present; |
---|
101 | ii) ECAL+HCAL, that is the electromagnetic calorimeter (ECAL) |
---|
102 | is placed in front of the hadronic calorimeter. |
---|
103 | ECAL is made of 23 cm long PbWO4 crystals (corresponding to about |
---|
104 | 25.8 radiation lengths, and 1.1 interaction lengths); for the |
---|
105 | test beam a 7 x 7 = 49 matrix of crystals is used. |
---|
106 | HCAL is a sampling calorimeter, with plastic scintillator as sensitive |
---|
107 | part and copper as absorber. 28 scintillator plates were used with |
---|
108 | absorber of varying thickness in between, and also varying thickness |
---|
109 | and type of scintillator. More precisely: |
---|
110 | --- layer 1: 2 cm of Copper |
---|
111 | --- layer 2 to 7: 4 cm of Copper |
---|
112 | --- layer 8 to 21: 6 cm of Copper |
---|
113 | --- layer 22 to 27: 8 cm of Copper |
---|
114 | For the scintillators: 2 mm passive Plastic; 4 mm active Plastic; |
---|
115 | 1 mm passive Plastic. |
---|
116 | The total length of HCAL consists of 152 cm of Copper plus 189 mm of Plastic. |
---|
117 | The dimension orthogonal to the beam direction is 64 cm x 64 cm. |
---|
118 | The ECAL and HCAL considered here are prototypes for the Central and |
---|
119 | Endcap calorimeters of the CMS detector (which covers the rapidity |
---|
120 | region |eta| < 3.0 ; CMS has also a Forward calorimeter, which covers |
---|
121 | the region 3.0 < |eta| < 5.0, but this part was not considered in |
---|
122 | this test-beam setup). Notice, however, that there are more layers |
---|
123 | (28 instead of 19 in the Barrel or 18 in the Endcap) of HCAL in the |
---|
124 | test-beam setup than in the real CMS detector, in order to study |
---|
125 | energy containment. Therefore, the ECAL+HCAL in the test-beam amounts |
---|
126 | to more than 11 radiation lengths as for the real CMS detector (the |
---|
127 | 19 layers of the Barrel have each 6 cm of absorber, whereas the |
---|
128 | 18 layers of the Endcap have each 6.6 cm of absorber, so that the |
---|
129 | number of interaction lengths are rougly the same). |
---|
130 | Five values of the magnetic field (parallel to the face of the scintillators) |
---|
131 | have been considered in the test-beam: 0.0 , 0.375 , 0.75 , 1.50 , 3.0 Tesla. |
---|
132 | |
---|
133 | In order to set the magnetic field, you have to edit the file |
---|
134 | dataglobal/fmap.tb96 |
---|
135 | and change the first number (which appears in the third line of |
---|
136 | that file, on the first column; the unit being Tesla): |
---|
137 | #. Field map |
---|
138 | *DO FLDM |
---|
139 | 0.0 9 652.0 |
---|
140 | for example, if you want a magnetic field of 3.0 Tesla the last |
---|
141 | line must be set as follows (the magnetic field unity is kilo Gauss). |
---|
142 | 30.0 9 652.0 |
---|
143 | |
---|
144 | The default stepper in magnetic field is G4ClassicalRK4, but other |
---|
145 | possibilities can be selected by editing the file |
---|
146 | src/CCalDetectorConstruction.cc (look at the string "***STEPPER***"). |
---|
147 | |
---|
148 | In order to deactivate either the ECAL or the HCAL, it is enough |
---|
149 | to comment out the corresponding line in the file g4testbeamhcal96.conf, |
---|
150 | using "#" as the comment character. For instance, to have only the HCAL |
---|
151 | without ECAL: |
---|
152 | "HcalTB96" "tbhcal96" 1 |
---|
153 | #"CrystalMatrixModule" "tbhcal96xtal" 1 |
---|
154 | |
---|
155 | |
---|
156 | In this test-beam setup, at the back of ECAL, there is also some |
---|
157 | material for support and readout, which has been considered in the |
---|
158 | simulation. For the HCAL, only the fibres are close to the test-beam, |
---|
159 | and because they have the same composition as the scintillators |
---|
160 | they are adequately represented in the simulation; the remaining |
---|
161 | of the readout, including the photomultipliers, are in readout boxes |
---|
162 | far away from the HCAL, and hence are not present in the simulation. |
---|
163 | |
---|
164 | Let's summarizes now the geometry description of the simulation. |
---|
165 | As said in the introduction, this part is the most original and |
---|
166 | important of this example, but it is quite complex and can be fully |
---|
167 | appreciated only in the context of the CMS software framework, in |
---|
168 | particular in the relation between Simulation, Reconstruction, and |
---|
169 | Visualization. Therefore we limit ourself to only few considerations, |
---|
170 | pointing to the internal CMS documentation for more details. |
---|
171 | |
---|
172 | --- In order to share the same geometrical and physical information |
---|
173 | about CMS between Simulation, Reconstruction, and Visualization, |
---|
174 | avoiding inconsistencies, duplications, and unnecessary dependecies, |
---|
175 | all these information is store, once for all, in common databases |
---|
176 | (typically in XML format), instead of putting them inside C++ classes, |
---|
177 | as usually done in simpler detector descriptions (in most of the |
---|
178 | the Geant4 examples, novice or advanced, the geometry information |
---|
179 | is kept inside the concrete class which inherits from |
---|
180 | G4VUserDetectorConstruction). For simplicity, in this example, |
---|
181 | these "databases" are nothing more than ASCII files: |
---|
182 | |
---|
183 | datageom/ : tbhcal96.geom, tbhcal96hcal.geom, tbhcal96xtal.geom |
---|
184 | store the information about the experimental Hall, |
---|
185 | the HCAL, and the ECAL, respectively. |
---|
186 | |
---|
187 | dataconf/ : g4testbeamhcal96.conf, testbeamhcal96.conf |
---|
188 | store the information about which configuration |
---|
189 | (HCAL only, or ECAL+HACL) is considered, in the |
---|
190 | Simulation and Reconstruction, respectively. |
---|
191 | |
---|
192 | dataglobal/ : fmap.tb96, material.cms, rotation.cms |
---|
193 | The first one is the magnetic field map (how the |
---|
194 | intensity of the magnetic field, in the direction |
---|
195 | orthogonal to the beam direction, varies along |
---|
196 | the beam axis). The second one, material.cms, |
---|
197 | keeps the full collection of all materials used in |
---|
198 | the CMS detector (not only in the calorimeters, |
---|
199 | although we are simulating only them in this example!). |
---|
200 | The third one, rotation.cms, collects a set of useful |
---|
201 | rotation parameters (angles). |
---|
202 | |
---|
203 | datavis/ : tbhcal96.vis, tbhcal96hcal.vis, tbhcal96xtal.vis |
---|
204 | visualization information for, respectively, the |
---|
205 | experimental Hall, HCAL, and ECAL. |
---|
206 | |
---|
207 | --- In order to allow an high degree of flexibility, at the geometry |
---|
208 | level the user can choose which subsystem of the detector setup |
---|
209 | should be simulated and can activate or deactivate the sensitive |
---|
210 | parts, subsystem by subsystem. This can be done at run time, |
---|
211 | by modifying one of the above database information, without need |
---|
212 | of putting the hands on the code, recompiling, etc. |
---|
213 | |
---|
214 | --- There are two "parallel geometry factories": one described by "core" |
---|
215 | classes, which are independent from the Simulation (and therefore |
---|
216 | can be used, for instance, by the Reconstruction); and one which |
---|
217 | is specific of the Simulation. In the latter case (Geant4 side of |
---|
218 | the geometry model), all the geometry factories are derived from the |
---|
219 | base class CCalG4Albe. Furthermore, using double inheritance, each |
---|
220 | of them derives also from the counterpart in the "core" hierarchy. |
---|
221 | The design of the CCalG4Able class helps a modular approach and easy |
---|
222 | interchanging at the level of subdetectors, allowing a straightforward |
---|
223 | transition from the simulation of the entire CMS detector to that of |
---|
224 | just a part of it, or to a test-beam geometry, as indeed in this example. |
---|
225 | Of course this modular, flexible, and general approach does not come |
---|
226 | for free: the price to pay here is its complexity, which would be |
---|
227 | otherwise unjustified if we limited ourself to the pure simulation |
---|
228 | of a relatively simple test-beam setup. |
---|
229 | |
---|
230 | --- See "10. Classes Overview" below for a schematic summary of the |
---|
231 | various classes involved in the Geometry description of this example. |
---|
232 | |
---|
233 | |
---|
234 | 4. Physics processes |
---|
235 | -------------------- |
---|
236 | |
---|
237 | By the default, one of the ufficial High Energy Physics List for |
---|
238 | Calorimetry, QGSC, is used in this example. However, it is |
---|
239 | very easy to use instead either LHEP or QGSP. To do so, it is |
---|
240 | enough to comment/uncomment a line in the main CompositeCalorimeter.cc : |
---|
241 | for example, if you want to use LHEP instead of the default QGSC |
---|
242 | you have to change it as follows: |
---|
243 | |
---|
244 | //***LOOKHERE*** CHOOSE THE PHYSICS LIST. |
---|
245 | runManager->SetUserInitialization(new LHEP); // LHEP |
---|
246 | // runManager->SetUserInitialization(new QGSP); // QGSP |
---|
247 | // runManager->SetUserInitialization(new QGSC); // QGSC |
---|
248 | //***endLOOKHERE*** |
---|
249 | |
---|
250 | Notice that, for most of the cases (and certainly also in this case |
---|
251 | in which we don't even take into account the beam profile, noise |
---|
252 | and digitization!) the faster LHEP Physics List would be good enough |
---|
253 | for calorimetry studies. However, we prefer to use, as default, the |
---|
254 | more sophisticated (but slower) QGSC Physics List for the learning |
---|
255 | purposes of this example. |
---|
256 | |
---|
257 | |
---|
258 | 5. Particle Generator |
---|
259 | --------------------- |
---|
260 | |
---|
261 | The 1996 test-beam has been taken with the following particles: |
---|
262 | --- 225 GeV muons (for calibration) |
---|
263 | --- 10 to 300 GeV pions |
---|
264 | --- 10 to 300 GeV electrons |
---|
265 | therefore the standard Geant4 Particle Gun has been used as primary |
---|
266 | generator. Notice that, for the sake of keeping the example not too |
---|
267 | complicated, the proper simulation of the beam profile and |
---|
268 | beam contamination have been neglected. |
---|
269 | |
---|
270 | |
---|
271 | 6. Hits |
---|
272 | ------- |
---|
273 | |
---|
274 | In CMS there are two groups of hits: Tracker-like and Calorimeter-like. |
---|
275 | Only the latter one appears in this example. |
---|
276 | For the same reasons, as seen for the Geometry, of consistency without |
---|
277 | duplication of information and unnecessary coupling between Simulation, |
---|
278 | Reconstruction, and Visualization, the simulation calorimeter hit class, |
---|
279 | CCalG4Hit, doubly inherits from the common Geant4 abstract class for |
---|
280 | all hits, G4VHit, and from the "core" (i.e. simulation independent) |
---|
281 | CMS calorimeter hit class, CCalHit. |
---|
282 | A new Hit object is created |
---|
283 | - for each new particle entering the calorimeter; |
---|
284 | - for each detector unit (i.e cristal or fiber or scintillator layer); |
---|
285 | - for each nanosecond of the shower development; |
---|
286 | The information stored in each CCalHit object is the following: |
---|
287 | - Entry : local coordinates of the entrance point of the particle |
---|
288 | in the unit where the shower starts; |
---|
289 | - the TrackID : Identification number of the incident particle; |
---|
290 | - the IncidentEnergy : kinetic energy of that incident particle; |
---|
291 | - the UnitID : the identification number of the detector unit |
---|
292 | (crystal, or fiber, or scintillator layer); |
---|
293 | - the TimeSlice : the time interval, in nanoseconds, in which the |
---|
294 | hit has been created; |
---|
295 | - the EnergyDeposit : the energy deposit in this hit. |
---|
296 | Notice that all hit objects created for a given shower have the same |
---|
297 | values for the first three pieces of information. |
---|
298 | |
---|
299 | |
---|
300 | No Noise and Digitization |
---|
301 | -------------------------- |
---|
302 | |
---|
303 | In order to keep the complexity of this example to a reasonable |
---|
304 | level, both noise and digitization effects have not been included. |
---|
305 | |
---|
306 | |
---|
307 | 7. User Actions |
---|
308 | ---------------- |
---|
309 | |
---|
310 | In this example. there have been used the following User Actions: |
---|
311 | |
---|
312 | --- G4UserRunAction (the derived, concrete class is CCalRunAction): |
---|
313 | it is used to invoke the Analysis object at the beginning of |
---|
314 | the Run, to instantiate it and passing it the Run number, and |
---|
315 | at the end of the Run, to inform it that the Run is finished |
---|
316 | and therefore the histograms, ntuples, etc. must be closed. |
---|
317 | |
---|
318 | --- G4UserEventAction (the derived, concrete class is CCalEndOfEventAction): |
---|
319 | it is used to examine, at the end of the Event, all collected |
---|
320 | (calorimeter) hits, extract the various observables which are |
---|
321 | interesting (to the goal of understanding things like: the effect |
---|
322 | of magnetic field on scintiallator; choice of the absorber |
---|
323 | thickness by optimizing resolution versus containment; impact of |
---|
324 | the absorber depth in the energy caontainment; electromagnetic |
---|
325 | calorimeter contribution in the electron - pion separation; etc.) |
---|
326 | and finally call the analysis object to store such selected |
---|
327 | information on histograms and/or in the ntuple. |
---|
328 | The name of the class "CCalEndOfEventAction" is motivated by the |
---|
329 | fact that at the beginning of the Event nothing is done. |
---|
330 | |
---|
331 | --- G4UserSteppingAction (the derived, concrete class is CCalSteppingAction): |
---|
332 | it is used to extract some "unphysical" information (that is not |
---|
333 | experimentally measurable, although interesting for a better |
---|
334 | understanding of the shower development), namely the lateral profile |
---|
335 | and the deposit as a function of the time (see "8.Analysis/Histogramming |
---|
336 | for more details"), which is available only from simulation, and then, |
---|
337 | at the end of Event, the analysis object is invoked to store such |
---|
338 | information on histograms. |
---|
339 | Please notice that the stepping action is not used to create hits. |
---|
340 | |
---|
341 | --- G4UserStackingAction (the derived, concrete class is CCalStackingAction): |
---|
342 | it is used to ensure that the same track ID of the particle |
---|
343 | originating a shower appears in all hits (calorimeter hit objects |
---|
344 | of class CCalHit) of the shower, in any calorimeter part. |
---|
345 | |
---|
346 | |
---|
347 | 8. Analysis / Histogramming |
---|
348 | ---------------------------- |
---|
349 | |
---|
350 | The analysis part of CompositeCalorimeter is kept in class CCalAnalysis, |
---|
351 | and is based on the AIDA interfaces and their implementation in PI. |
---|
352 | Please take a look to the web page: http://www.cern.ch/PI . |
---|
353 | Both the histograms and the ntuple are saved at the end of the run in the |
---|
354 | HBOOK file "ccal.his". You can than analyze offline the contents of such |
---|
355 | a file, using Lizard (or any other AIDA-compliant package) or with |
---|
356 | Paw or Root. Please note that in a multiple run session, the last run |
---|
357 | always override the HBOOK file. |
---|
358 | What the histograms and the variables of the ntuple represent is |
---|
359 | explained below: |
---|
360 | |
---|
361 | Histograms 100 - 127 : energy deposit (in GeV) in the sensitive part |
---|
362 | (plastic scintillator layer) of one Hadronic |
---|
363 | calorimeter module (there are 28 modules, numbered |
---|
364 | from 0 to 27, and the corresponding histogram has |
---|
365 | ID = 100 + number of module). |
---|
366 | Ntuple variables hcal0 - hcal27 : provide the same information. |
---|
367 | |
---|
368 | Histograms 200 - 248 : energy deposit (in GeV) in one crystal |
---|
369 | electromagnetic towers (there are a matrix of |
---|
370 | 7 x 7 = 49 towers, numbered from 0 to 48, and |
---|
371 | the corresponding histogram has |
---|
372 | ID = 200 + number of tower). |
---|
373 | Ntuple variables ecal0 - ecal48 : provide the same information. |
---|
374 | |
---|
375 | Histograms 300 - 339 : total energy deposit (in GeV) in any |
---|
376 | electromagnetic crystal tower or hadronic module |
---|
377 | (either in a sensitive or insensitive layer) |
---|
378 | in one of the 40 nanosecond time slices: in other |
---|
379 | words, histogram 300+I , where I = 0 - 39, |
---|
380 | contains the total deposit energy between |
---|
381 | I and I+1 nanoseconds after the "collision". |
---|
382 | (Notice that the time window considered, |
---|
383 | 40 nanoseconds, is larger than the LHC |
---|
384 | bunch-crossing of 25 nanoseconds.) |
---|
385 | |
---|
386 | Histograms 400 - 469 : energy profile (in GeV), summed over all layers |
---|
387 | sensitive (plastic scintillator) and insensitive |
---|
388 | (copper absorber), as a function of the radial |
---|
389 | distance (in centimeter) from the beam axis |
---|
390 | ( ID histo = 400 + radial distance in cm ). |
---|
391 | |
---|
392 | Histogram 4000 : total energy deposit (in GeV) in the sensitive parts |
---|
393 | of either the electromagnetic or hadronic calorimeters. |
---|
394 | Ntuple variable edep provides the same information. |
---|
395 | |
---|
396 | Other ntuple variables are the following: |
---|
397 | --- elab : energy (in GeV) of the incident particle. |
---|
398 | --- xpos, ypos, zpos : position (in mm) from where the projectile |
---|
399 | has been shot. |
---|
400 | --- edec, edhc : total energy deposit (in GeV) in the sensitive |
---|
401 | parts of, respectively, the electromagnetic |
---|
402 | and hadronic calorimeters. Notice that their |
---|
403 | sum edec+edhc coincides with edep |
---|
404 | |
---|
405 | Notice that lateral profile (400-469) and time-slice (300-339) |
---|
406 | histograms show purely Monte Carlo quantities, which cannot be |
---|
407 | experimentally measured. |
---|
408 | Please be careful that the range of the histograms has been chosen |
---|
409 | in such a way to contain most of the entries, but only few histograms |
---|
410 | fill a large fraction of that range, whereas the remaining majority |
---|
411 | fill only the first few bins (corresponding to lower energy), and, |
---|
412 | therefore, when plotted they look almost empty, but they are not, |
---|
413 | and the results are sensible. We suggest to plot the ntuple's variables, |
---|
414 | rather than the histograms, when the same information is available |
---|
415 | from the ntuple. |
---|
416 | |
---|
417 | |
---|
418 | 9. Visualization / GUI |
---|
419 | ----------------------- |
---|
420 | |
---|
421 | If you setup one of the following Geant4 environmental variables: |
---|
422 | G4VIS_USE_DAWN |
---|
423 | G4VIS_USE_VRML |
---|
424 | G4VIS_USE_OPENGLX |
---|
425 | which correspond to the use of DAWN, VRML, and OPENGLX, respectively, |
---|
426 | as visualization engine of Geant4, and set properly the corresponding |
---|
427 | PATH as well, it is then possible to visualize the detector and also |
---|
428 | some events. |
---|
429 | To do so, you have to run |
---|
430 | > $G4WORKDIR/bin/$G4SYSTEM/CompositeCalorimeter |
---|
431 | without input file: you then see the detector; after that, |
---|
432 | you can select the particle gun and its energy, in the |
---|
433 | case you want something different from the the default |
---|
434 | (which is a 100 GeV pi-), for example: |
---|
435 | Idle> /gun/particle e- |
---|
436 | Idle> /gun/energy 200 GeV |
---|
437 | and then run some events, for example: |
---|
438 | Idle> /run/beamOn 3 |
---|
439 | |
---|
440 | Notice that, by default, OGLIX is used for the visualization, |
---|
441 | because it is quite fast and it does not produce any files in |
---|
442 | output. However, you can always choose something else, for example |
---|
443 | VRML2FILE or DAWNFILE, either interactively as follows: |
---|
444 | Idle> /vis/open DAWNFILE |
---|
445 | or by changing the default, by editing the file (main program) |
---|
446 | CompositeCalorimeter.cc and comment/uncomment the lines |
---|
447 | in such a way to have, at the end: |
---|
448 | visCommand = "/vis/open DAWNFILE"; |
---|
449 | // visCommand = "/vis/open VRML2FILE"; |
---|
450 | // visCommand = "/vis/open OGLIX"; |
---|
451 | |
---|
452 | The tracks that are shown include both charged and neutral particles |
---|
453 | of any momentum: if you want instead only charged, or only neutral, |
---|
454 | then you have simply to edit src/CCalEndOfEventAction.cc |
---|
455 | at the end of the method EndOfEventAction and uncomment the line |
---|
456 | where the condition on the charge is made (it should then be |
---|
457 | straighforward to eventual add some other conditions, for example |
---|
458 | if you want to see only those particles that satisfy certain |
---|
459 | kinematic conditions). |
---|
460 | |
---|
461 | Rather than to specify "by hand" the type of particle gun, |
---|
462 | its energy, and the number of events, it is possible to have |
---|
463 | a very simple GUI (graphical user interface) from which to make |
---|
464 | such choices, between a limited set of possibilities, via menus. |
---|
465 | Such GUI is based on Motif XmCommand widget, but it would be |
---|
466 | straightforward, eventually, to make the necessary changes |
---|
467 | in order to use a different one. |
---|
468 | The only thing you need to do to get the GUI is to setup |
---|
469 | the following Geant4 environmental variables: |
---|
470 | G4UI_BUILD_XM_SESSION=1 |
---|
471 | G4UI_USE_XM=1 |
---|
472 | Then, if you run the executable without specifying a macro file |
---|
473 | (like test.g4mac): |
---|
474 | > $G4WORKDIR/bin/$G4SYSTEM/CompositeCalorimeter |
---|
475 | a window automatically pops out, with the menus where you |
---|
476 | can make your selection of particle type, energy, and number |
---|
477 | of events to be run. |
---|
478 | |
---|
479 | |
---|
480 | 10. Classes Overview |
---|
481 | --------------------- |
---|
482 | |
---|
483 | This is a schematic overview of the classes defined in this example: |
---|
484 | |
---|
485 | CCalPrimaryGeneratorAction |
---|
486 | CCalPrimaryGeneratorMessenger |
---|
487 | User action for primaries generator. |
---|
488 | |
---|
489 | CCalDetectorConstruction |
---|
490 | CCalAMaterial |
---|
491 | CCalDataSet |
---|
492 | CCalDetector |
---|
493 | CCalEcal |
---|
494 | CCalEcalOrganization |
---|
495 | CCalG4Able |
---|
496 | CCalG4Ecal |
---|
497 | CCalG4Hall |
---|
498 | CCalG4Hcal |
---|
499 | CCalGeometryConfiguration |
---|
500 | CCalHall |
---|
501 | CCalHcal |
---|
502 | CCalHcalOrganization |
---|
503 | CCalMagneticField |
---|
504 | CCalMaterial |
---|
505 | CCalMaterialFactory |
---|
506 | CCalRotationMatrixFactory |
---|
507 | CCalVOrganization |
---|
508 | CCalVisManager |
---|
509 | CCalVisualisable |
---|
510 | CCaloOrganization |
---|
511 | CCalutils |
---|
512 | Geometry and material definitions for the detector. |
---|
513 | Notice in particular that: |
---|
514 | CCalHall, CCalEcal, CCalHcal derive from CCalDetector; |
---|
515 | CCalG4Hall, CCalG4Ecal, CCalG4Hcal derive from the above |
---|
516 | corresponding classes and from CCalG4Able; |
---|
517 | CCalEcalOrganization, CCalHcalOrganization derive from |
---|
518 | CCalVOrganization : each sensitive cell has an unique |
---|
519 | number for detector organization (this is a software |
---|
520 | ID not an hardware/electronic one). |
---|
521 | |
---|
522 | CCalHit |
---|
523 | CCalG4Hit |
---|
524 | CCalG4HitCollection |
---|
525 | CCalSDList |
---|
526 | CCalSensAssign |
---|
527 | CCalSensitiveConfiguration |
---|
528 | CCalSensitiveDetectors |
---|
529 | CCaloSD |
---|
530 | Hit and Sensitive Detectors. |
---|
531 | Notice in particular that: |
---|
532 | CCalG4Hit derives from G4VHit and CCalHit; |
---|
533 | CCaloSD derives from G4VSensitiveDetector. |
---|
534 | |
---|
535 | CCalAnalysis |
---|
536 | Analysis manager class which uses Anaphe. |
---|
537 | |
---|
538 | CCalRunAction |
---|
539 | User run action class. |
---|
540 | |
---|
541 | CCalEndOfEventAction |
---|
542 | User event action class. |
---|
543 | |
---|
544 | CCalStackingAction |
---|
545 | User Stacking action class. |
---|
546 | |
---|
547 | CCalSteppingAction |
---|
548 | User Stepping action class. |
---|
549 | |
---|