From 518eb85250b0656c862cd657a7276956073981d8 Mon Sep 17 00:00:00 2001 From: ivana Date: Wed, 11 Jul 2007 08:23:25 +0000 Subject: [PATCH] README* files replaced with README*.txt adapdetd for Doxygen --- MUON/{README => README.txt} | 123 +++++---- MUON/{READMEcalib => READMEcalib.txt} | 36 ++- ...{READMEevaluation => READMEevaluation.txt} | 30 ++- MUON/{READMEfast => READMEfast.txt} | 17 +- MUON/{READMEgeometry => READMEgeometry.txt} | 118 ++++---- MUON/READMEmapping | 231 ---------------- MUON/READMEmapping.txt | 255 ++++++++++++++++++ MUON/{READMEraw => READMEraw.txt} | 19 +- MUON/{READMEshuttle => READMEshuttle.txt} | 56 ++-- MUON/{READMEtrigger => READMEtrigger.txt} | 126 +++++---- 10 files changed, 571 insertions(+), 440 deletions(-) rename MUON/{README => README.txt} (85%) rename MUON/{READMEcalib => READMEcalib.txt} (93%) rename MUON/{READMEevaluation => READMEevaluation.txt} (87%) rename MUON/{READMEfast => READMEfast.txt} (76%) rename MUON/{READMEgeometry => READMEgeometry.txt} (76%) delete mode 100644 MUON/READMEmapping create mode 100644 MUON/READMEmapping.txt rename MUON/{READMEraw => READMEraw.txt} (86%) rename MUON/{READMEshuttle => READMEshuttle.txt} (95%) rename MUON/{READMEtrigger => READMEtrigger.txt} (67%) diff --git a/MUON/README b/MUON/README.txt similarity index 85% rename from MUON/README rename to MUON/README.txt index c1489f4b8a5..0f053c50781 100644 --- a/MUON/README +++ b/MUON/README.txt @@ -1,30 +1,40 @@ -$Id$ +// $Id$ -========================================================== +/*! + +\page README_main README main + Please add to this README file all information concerning general items about the MUON code or the libraries -base, simu and reco -Other README file of the muon code are -READMEevaluation -READMEgeometry -READMEraw -READMEshuttle -READMEtrigger - -========================================================== - How to check that your aliroot is working well -========================================================== +\ref base, \ref sim and \ref rec. + +Other README pages of the muon code are +- \ref README_raw +- \ref README_mapping +- \ref README_calib +- \ref README_geometry +- \ref README_trigger +- \ref README_shuttle +- \ref README_evaluation +- \ref README_fast + +\section s1 How to check that your aliroot is working well + There is a script file AlirootRun_MUONtest.sh which allows for simulating, reconstructing and making the invariant analysis of the generated Upsilon (1S). The used configuration file is Config.C in MUON directory. + You have to type : +
 $ALICE_ROOT/MUON/AlirootRun_MUONtest.sh [option]
+
The complete list of the option is printed when you call the script with whatever non valid option, .eg. h: +
 ./AlirootRun_MUONtest.sh h
 ERROR : extra option not recognized
 Usage: AlirootRun_MUONtest.sh options (-SRXsrxn:p:d:c:)
@@ -35,6 +45,7 @@ Usage: AlirootRun_MUONtest.sh options (-SRXsrxn:p:d:c:)
        -p recoptions (quotified string) reconstruction options to use (default "SAVEDIGITS")
        -d full path to output directory (default /work/projects/alice/dev/AliRoot/MUON/test_out.100)
        -c full path to configuration file for simulation (default /work/projects/alice/dev/AliRoot/MUON/Config.C)
+
The results of this test are saved in test_out.nevent directory. Please note that the CDB (Condition DataBase) is now always *required* @@ -43,9 +54,8 @@ of that CDB is stored in CVS, so you should have one already in MUON/Calib subdirectories. -========================================================== - How to check that your aliroot is working VERY well -========================================================== +\section s2 How to check that your aliroot is working VERY well + There is a script file AlirootRun_MUONlongtest.sh which allows for simulating, reconstructing and making the -+invariant analysis of the generated Upsilon (1S). @@ -53,12 +63,15 @@ This script generates a large number of Upsilon (20k) in order to access differential quantities. The used configuration file is Config.C in MUON directory. + One should really run this script to check if the MUON code can process a large number of events WITHOUT errors, in particular before making important commits !! You have to type : +
 $ALICE_ROOT/MUON/AlirootRun_MUONtestlong.sh
+
The results of this test are saved in testlong_out/ directory and will be kept in CVS @@ -66,35 +79,37 @@ and will be kept in CVS and MUONplotEfficiency.C are also able to handle J/Psi if Config.C is modified accordingly ) -========================================================== - How to run a MUON generation -========================================================== +\section s3 How to run a MUON generation + You only need to run the simulation part of the test script AlirootRun_MUONtest.sh -============================================================ - How to dump the content of Root data files -============================================================ +\section s4 How to dump the content of Root data files + To check the content of Root data files, the AliMUON*DataInterface classes provides the functions to produce an ASCII output on the screen which can be redirected on the file: for MC information, use AliMUONMCDataInterface : +
 > aliroot (or root with just the loading of MUON libs, see loadlibs.C)
 root [0] AliMUONMCDataInterface mcdi("galice.root");
 root [1] mcdi.DumpKine(5);       > dump.kine
 root [2] mcdi.DumpHits(5);       > dump.hits
 root [3] mcdi.DumpTrackRefs(5);  > dump.trackrefs
+
for all other information, use AliMUONDataInterface : +
 > aliroot
 root [0] AliMUONDataInterface di("galice.root");
 root [1] di.DumpDigits(5);     > dump.digits
 root [2] di.DumpSDigits(5);    > dump.sdigits
 root [3] di.DumpRecPoints(5);  > dump.recpoints
 root [4] di.DumpTrigger(5); > dump.rectrigger
+
Remind that during simulation and reconstruction two differents galice.root are generated: one for the generation @@ -106,9 +121,8 @@ root [1] mcdi.DumpKine(5); W-AliRunLoader::GetEvent: Stack not found in header E-TFile::TFile: file ./Kinematics.root does not exist -============================================================ - Tracking parameters, cuts, energy loss and physics processes -============================================================ +\section s5 Tracking parameters, cuts, energy loss and physics processes + Tracking parameters in MUON are automatically defined by GEANT MUON takes the default values of CUTs and physics processes defined by the Config files, except for the gas mixture medium @@ -118,9 +132,8 @@ in the data directory. In particular ILOSS parameter MUST be equal unity (1) in order simulate a realistic energy loss distribution (mean value and fluctuations) in the active gas. -============================================================ - Tracking of particle in the magnetic field -============================================================ +\section s6 Tracking of particle in the magnetic field + GEANT has two ways for tracking charged particles in the magnetic field: HELIX et RKUTA. HELIX is faster and works well if the gradient of magnetic @@ -129,16 +142,17 @@ For MUON, HELIX is a not a good approximation and we must use RKUTA to get the optimal mass resolution of the spectrometer. The choice of HELIX or RKUTA is done in the config file when the magnetic field is defined: +
   AliMagFMaps* field = new AliMagFMaps("Maps","Maps", TRACKING, FACTOR, MAXB, AliMagFMaps::k5kG);
   gAlice->SetField(field);
+
TRACKING must be 1 for RKUTA and 2 for HELIX (the default value for aliroot is 2 (HELIX)) FACTOR allows you to set the magnetic field to 0, just putting FACTOR=0. Default value is 1. MAXB is the maximum magnetic field which is 10.T -=========================================================== - How to tune muon track reconstruction -=========================================================== -several options and adjustable parameters are available for both Kalman and Original +\section s7 How to tune muon track reconstruction + +Several options and adjustable parameters are available for both Kalman and Original tracking algorithms (hard coded for the moment in AliMUONVTrackReconstructor.cxx): - *fgkSigmaToCutForTracking* : quality cut used to select new clusters to be attached to the track candidate and to select good tracks. @@ -157,9 +171,8 @@ tracking algorithms (hard coded for the moment in AliMUONVTrackReconstructor.cxx - *fgkSigmaToCutForImprovement* : quality cut used when we try to improve the quality of the tracks. -=========================================================== - MUON cocktail for physics .............. -=========================================================== +\section s8 MUON cocktail for physics .............. + There is a MUON cocktail generator of the muon sources in the EVGEN directory. This class derives from AliGenCocktail. In the init of this class I have filled the cocktail with @@ -179,6 +192,7 @@ there are 2 data members in the class fNsuceeded adn fNGenerate which tell us what is the biais source. Enclose an example to use this generator: +
 AliGenMUONCocktail * gener = new AliGenMUONCocktail();
 gener->SetPtRange(1.,100.);       // Transverse momentum range  
 gener->SetPhiRange(0.,360.);    // Azimuthal angle range 
@@ -191,10 +205,10 @@ gener->SetVertexSmear(kPerTrack);
 gener->SetOrigin(0,0,0);        // Vertex position
 gener->SetSigma(0,0,0.0);       // Sigma in (X,Y,Z) (cm) on IP position
 gener->Init();
+
-========================================================== -How to simulate events with misaligned geometry in local CDB -========================================================== + +\section s9 How to simulate events with misaligned geometry in local CDB If you want to use a misaligned geometry to simulate some events you can use a local CDB. For this need to follow @@ -214,6 +228,7 @@ default storage and set the specific storage for MUON/Align/Data, before instantiating AliSimulation (see for example the commented lines AlirootRun_MUONtest.sh). +
 aliroot -b  >& testSim.out << EOF
 AliCDBManager* man = AliCDBManager::Instance();
 man->SetDefaultStorage("local://$ALICE_ROOT");
@@ -223,11 +238,9 @@ MuonSim.SetWriteRawData("MUON");
 MuonSim.Run(10);
 .q
 EOF
+
- -========================================================== - How to Merge events -========================================================== +\section s10 How to Merge events You can merge 2 types of simulated events. For example, you can simulate Hijing events, and then simulate muons @@ -243,11 +256,13 @@ won't need Kinematics files of the Hijing simulation... Hijing simulation +
 aliroot -b << EOF
 AliSimulation HijingSim("$HIJING_SIM/YourConfigForHIJING.C")
 HijingSim.Run(5)
 .q
 EOF
+
You cand build YourConfigFroHIJING.C File from the ConfigPPR file in AliRoot/macros module. @@ -257,7 +272,7 @@ merging both simulated events. In next example, we are merging 20 times each Hijing event in order to simulate 100 muons merged with 5 Hijing events. - +
 aliroot -b << EOF
 AliSimulation MuonSim("$ALICE_ROOT/MUON/Config.C")
 MuonSim.MergeWith("$HIJING_SIM/galice.root",20) //parameters are the Hijing simulation file and the number of times we use each Hijing event
@@ -277,10 +292,9 @@ MuonRec.SetFillESD("MUON")
 MuonRec.Run()
 .q
 EOF
+
-========================================================== -...on track numbering -========================================================== +\section s11 ...On track numbering All generated particles, including primary and secondary particles are put on the stack. The secondary particles are kept @@ -303,6 +317,7 @@ without a hit in MUON. The correspondence between "track ID" in the hits-tree ("itr") and the particle ID for particles on the stack (i.e. generated particles) can be obtained via: +
 for (Int_t itr = 0; itr < ntracks; itr++) {
     AliMUONVHitStore* hitStore = mcDataInterface.HitStore(event,itr);
     //track "itr" of the hits-tree
@@ -315,6 +330,7 @@ for (Int_t itr = 0; itr < ntracks; itr++) {
        TParticle* particle = mcDataInterface.Stack(event)->Particle(id);
     }  
 }
+
where mcDataInterface has been obtained by AliMUONMCDataInterface mcDataInterface("galice.root"); @@ -330,6 +346,7 @@ referred to in the hit-tree. To know which is the generated particle that deposited a given digit one has to follow the sequence of the kind: (shown here using the simple, but not fast, DataInterface interfaces) : +
 AliMUONMCDataInterface mcdi("galice.root");
 AliMUONDataInterface di("galice.root");
 
@@ -350,14 +367,15 @@ for (int tr = 0; tr < mDigit->Ntracks(); tr++)
     Int_t idTrack = mHit->Particle(); //gives flavour code of the particle
    }
 }
+
-=========================================================== - How to process invariant mass spectra for J/psi or Upsilon -=========================================================== +\section s12 How to process invariant mass spectra for J/psi or Upsilon + The macro MUONmassPlot_ESD.C reads back the MUON ESD informations and compute the invariant mass spectra and corresponding uncorelated background. Moreover gives the number of event in the resonance peak and the number of triggers. +
 Usage:
 root [0] .L $ALICE_ROOT/MUON/MUONmassPlot_ESD.C+
 root [1] MUONmassPlot_ESD(ExtrapToVertex, 
@@ -384,9 +402,8 @@ PtCutMin    (default 1):     keep only tracks with transverse momentum > PtCutMi
 PtCutMax    (default 10000): keep only tracks with transverse momentum < PtCutMax
 massMin     (default 9.17 for Upsilon) keep only invariant masses with 
 massMax     (default 9.77 for Upsilon) massMin < mass < massMax
+
+\section s13 Still working .............. - -=========================================================== - Still working .............. -=========================================================== +*/ diff --git a/MUON/READMEcalib b/MUON/READMEcalib.txt similarity index 93% rename from MUON/READMEcalib rename to MUON/READMEcalib.txt index ee5094129f9..c7e60373719 100644 --- a/MUON/READMEcalib +++ b/MUON/READMEcalib.txt @@ -1,26 +1,32 @@ -$Id$ +// $Id$ +/*! + +\page README_calib README calib + The Offline Condition DataBase is described extensively on ALICE Offline pages. Here you'll find only information relevant to the AliMUONCDB class (formerly MUONCDB.C macro), which defines a set of functions to read/write MUON information to this CDB. Those functions are not meant to be used as black boxes. + Please have a closer look before using (especially the ones writing to the CDB...) -------- -Calibration data objects -------- + +\section calib_s1 Calibration data objects We've designed generic data containers to store calibration information, tailored to the way we usually access MUON tracker data, that is, indexed by the pair (detElemId,manuId). This container is called AliMUONV2DStore. You can attach a TObject to every and each pair (detElemId,manuId). + For the moment, that TObject is generally of AliMUONVCalibParam type, which handles a given number of channels (64 typically) as a group. There's also an AliMUONV1DStore for data types which only requires indexing by 1 value (like trigger masks for instance). + As the class names suggest (V...), those classes are only interfaces. Concrete ones are AliMUON2DMap (used instead of a vector as detElemId are not contiguous) for the V2DStore, AliMUON1DArray (for things where indices are @@ -36,9 +42,8 @@ For trigger, the same virtual container idea applies, except we're using 1D container (AliMUONV1DStore, for masks) or specific ones (for LUT and efficiency) --------- -CDB location --------- + +\section calib_s2 CDB location One very important notion is that of the DefaultStorage (which you might set with AliCDBManager::Instance()->SetDefaultStorage(path)), which tells the CDB library where @@ -48,9 +53,8 @@ For local tests, path will be most likely = local://$ALICE_ROOT/MUON (i.e. there is, in CVS a slim version of the calibration objects needed for running the MUON code), or local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB for Shuttle testing. -------- -Writing to CDB -------- + +\section calib_s3 Writing to CDB AliMUONCDB class is used to populate the CDB with fake calibration objects for testing purposes. Real calibration data will normally be handled by the Shuttle (see READMEshuttle). @@ -61,28 +65,33 @@ A full set of calibration data types can be created from scratch using, from the Root prompt (from within the $ALICE_ROOT/MUON directory to get the correct list of libraries loaded by the loadlibs.C macro) +
 root[0] AliMUONCDB cdb;
 root[1] Int_t startRun = 0;
 root[2] Bool_t defaultValues = kTRUE;
 root[3] cdb.WriteTrigger(startRun);
 root[4] cdb.WriteTracker(defaultValues,startRun);
+
+ ------- -Reading the CDB ------- +\section calib_s4 Reading the CDB The actual reading is encapsulated into AliMUONCalibrationData class. e.g. to read pedestals for run 4567, one would do : +
 AliCDBManager::Instance()->SetDefaultStorage(cdbPath);
 AliMUONCalibrationData cd(4567);
 AliMUONV2DStore* ped = cd.Pedestals();
+
If you want to plot calibration data (not terribly usefull as it's a really global view), use the Plot() function of AliMUONCDB, e.g. +
 AliMUONCDB cdb(cdbpath);
 cdb.Plot(*ped,"pedestal")
+
which will create 2 histograms : pedestal_0 (mean) and pedestal_1 (sigma). @@ -90,4 +99,5 @@ You might also be interested in the AliMUONStoreHelper::Diff() method which generates an AliMUONV2DStore containing the difference (either absolute or relative) of two AliMUONV2DStore. +*/ diff --git a/MUON/READMEevaluation b/MUON/READMEevaluation.txt similarity index 87% rename from MUON/READMEevaluation rename to MUON/READMEevaluation.txt index a4652587901..78a27151b7d 100644 --- a/MUON/READMEevaluation +++ b/MUON/READMEevaluation.txt @@ -1,6 +1,11 @@ -============================================================ - How to run MUONRecoCheck macro -============================================================ +// $Id$ + +/*! + +\page README_evaluation README evaluation + + +\section evaluation_s1 How to run MUONRecoCheck macro To check the muon reconstruction by comparing the reconstructed tracks with the reference tracks made of "AliTrackReference" for the hits in chamber (0..9) @@ -10,19 +15,21 @@ momentum resolution ... but also to make physics analysis whenever track identification is needed. To compile MUONRecoCheck.C +
 .includepath $ALICE_ROOT/STEER
 .includepath $ALICE_ROOT/MUON
 .L $ALICE_ROOT/MUON/MUONRecoCheck.C+
+
-// To run MUONRecoCheck +To run MUONRecoCheck +
 MUONRecoCheck(nEvent,"geometry.root", "galice.root"); // nEvent = nb of events
+
-========================================================== -Macros for MC studies -========================================================== +\section evaluation_s2 Macros for MC studies -For MC studies the classes "AliMUONTrackLight" and "AliMUONPairLight" can be +For MC studies the classes AliMUONTrackLight and AliMUONPairLight can be used in order to fill not only the single muon / dimuon's kinematics (charge, pT, rapidity, etc) at the generation AND reconstruction level, but also for "decoding" the Pythia output and for the storing of the single muon's history. @@ -52,12 +59,19 @@ To read a generation/reconstrution from PDC06 preproduction, and write a file with a tree of AliMUONTrackLight / AliMUONPairLight : go to the directory containing the generation/reconstruction. From there run aliroot + +
 .L DecodeRecoCocktail.C+
 DecodeRecoCocktail();
 .q
+
To read the file previously generated: +
 aliroot
 .L ReadRecoCocktail.C+
 ReadRecoCocktail();
 .q
+
+ +*/ diff --git a/MUON/READMEfast b/MUON/READMEfast.txt similarity index 76% rename from MUON/READMEfast rename to MUON/READMEfast.txt index 11406f9d0a9..33ce1956160 100644 --- a/MUON/READMEfast +++ b/MUON/READMEfast.txt @@ -1,10 +1,13 @@ -$Id$ +// $Id$ -=========================================================== -How to test the fast simulation for MUON. -=========================================================== +/*! -The macro "fastMUONGen.C" allows to generate events using the +\page README_fast README fast + + +\section fast_s1 How to test the fast simulation for MUON. + +The macro fastMUONGen.C allows to generate events using the AliGenMUONCocktailpp generator. In the current implementation, the generator is set up in order to force all generated particles to decay within Pythia, including the muonic decay of pions and kaons: @@ -18,7 +21,7 @@ before the hadron absorber in order to "simulate" GEANT: gener->SetMuonOriginCut(-130.); The output of this generation ("galice.root" and "Kinematic.root") -can then be processed by the macro "fastMUONSim.C" that produces a +can then be processed by the macro fastMUONSim.C that produces a root file, called "fastSim_pp.root". It uses the "fast generator" to simulate the detector response. The output file contains TClonesArrays holding AliMUONTrackLight and AliMUONPairLight objects @@ -26,4 +29,6 @@ that are built on the basis of the surviving muons. Both macros can be run from fastSim.sh test script. +*/ + diff --git a/MUON/READMEgeometry b/MUON/READMEgeometry.txt similarity index 76% rename from MUON/READMEgeometry rename to MUON/READMEgeometry.txt index e3d0205c30a..6390bef843b 100644 --- a/MUON/READMEgeometry +++ b/MUON/READMEgeometry.txt @@ -1,15 +1,18 @@ - $Id$ +// $Id$ +/*! -=========================================================== -General Information about MUON Geometry -=========================================================== +\page README_geometry README geometry + + +\section geometry_s1 General Information about MUON Geometry Our geometry is described in the geometry builder classes. Main geometrical constants are set in the class AliMUONConstants. The code can then generate the geometry data files transform.dat and svmap.dat (see description below) via the macro MUONGenerateGeometryData.C (more info below). + The geometry data files have to be recreated each time the code of the geometry is modified. The info (well updated) in this files (svmap) is need during the simulation. @@ -29,57 +32,30 @@ Misalignments are in the official AliRoot code applied to the geometry.root file. -Geometry data files description - - transform.dat - ------------- - - List of transformations for chambers geometry modules and detection - elements; in format: - - KEY ID [nofDE] pos: posX posY posZ rot: theX phiX theY phiY theZ phiZ - - where KEY = CH or DE - ID = chamberId or detElemId - pos: posX posY posZ = position in cm - rot: theX phiX theY phiY theZ phiZ = rotation angles as in Geant3 in deg - - svmap.dat - ------------- - - Map of sensitive volumes to detction element Ids; - in format: - KEY volpath detElemId - - where KEY = SV - volpath = volume path in format /volname1_copyNo1/volname2_copyNo2/... - detElemId = detection element Id - +\section geometry_s2 How to check the Geometry with the new Geometrical modeler +\see ftp://root.cern.ch/root/doc/chapter16.pdf +\see http://agenda.cern.ch/fullAgenda.php?ida=a05212 -============================================================ - How to check the Geometry with the new Geometrical modeler - ftp://root.cern.ch/root/doc/chapter16.pdf - http://agenda.cern.ch/fullAgenda.php?ida=a05212 -============================================================ +
 gAlice->Init("$ALICE_ROOT/MUON/Config.C");
 gGeoManager->GetMasterVolume()->Draw();
+
+ + +\section geometry_s3 How to check the overlap with the new Geometrical modeler +\see ftp://root.cern.ch/root/doc/chapter16.pdf +\see http://agenda.cern.ch/fullAgenda.php?ida=a05212 -============================================================ - How to check the overlap with the new Geometrical modeler - ftp://root.cern.ch/root/doc/chapter16.pdf - http://agenda.cern.ch/fullAgenda.php?ida=a05212 -============================================================ +
 gAlice->Init("$ALICE_ROOT/MUON/Config.C");
 gGeoManager->CheckOverlaps();
 gGeoManager->PrintOverlaps();
+
- -=========================================================== - Macro MUONGenerateGeometryData.C -=========================================================== +\section geometry_s4 Macro MUONGenerateGeometryData.C Macro for generating the geometry data files @@ -97,24 +73,26 @@ input files must be re-generated via the macro MUONGenerateGeometryData.C To be run from aliroot: +
 .x MUONGenerateGeometryData.C
+
The generated files do not replace the existing ones but have different names (with extension ".out"). Replacement with new files has to be done manually. -=========================================================== - Macros to generate Mis-alignment data -=========================================================== +\section geometry_s5 Macros to generate Mis-alignment data -Macro for generating the geometry mis-alignment data: -MakeMUONFullMisAlignment.C -MakeMUONResMisAlignment.C -MakeMUONZeroMisAlignment.C +Macros for generating the geometry mis-alignment data: +- MakeMUONFullMisAlignment.C +- MakeMUONResMisAlignment.C +- MakeMUONZeroMisAlignment.C To be run from aliroot: +
 .x MakeMUONFullMisAlignment.C etc.
+
If the environment variable TOCDB is not set to "kTRUE", the misalignment data are generated in a local file: @@ -130,9 +108,8 @@ misalignment after all our alignment procedure has been applied. Full misalignment: Default is our current estimate of initial misalignment. -========================================================== -How to check the alignment software -========================================================== + +\section geometry_s6 How to check the alignment software The script AlirootRun_MUONtestAlign.sh allows you to check the software for the alignment with physics tracks. The script will: @@ -142,7 +119,9 @@ the alignment with physics tracks. The script will: - Run the alignment code over the above events using MUONAlignment.C To run you need to type: +
 $ALICE_ROOT/MUON/AlirootRun_MUONtestAlign.sh
+
The results of the test are saved in test_align/ directory. The file measShifts.root contains useful graphs for studying the alignment performances. A local CDB @@ -155,3 +134,34 @@ IMPORTANT NOTE: For a useful test of the alignment performances, the order of 100 000 tracks is needed, it is then advisable to generate and reconstruct enough events separately and run MUONAlignment.C providing a file list afterwards. + +\section geometry_s7 Geometry data files description + +\subsection geometry_s2_sub1 transform.dat + + List of transformations for chambers geometry modules and detection + elements; in format: +
 
+ KEY   ID  [nofDE]  pos: posX posY posZ  rot: theX phiX theY phiY theZ phiZ
+  
+ where  KEY  = CH or DE
+        ID   = chamberId or detElemId
+	pos: posX posY posZ  = position in cm
+	rot: theX phiX theY phiY theZ phiZ = rotation angles as in Geant3 in deg
+
+ +\subsection geometry_s2_sub2 svmap.dat + + Map of sensitive volumes to detction element Ids; + in format: + +
 
+ KEY  volpath  detElemId
+  
+ where  KEY  = SV
+	volpath   = volume path in format /volname1_copyNo1/volname2_copyNo2/...
+        detElemId = detection element Id
+
+ + +*/ diff --git a/MUON/READMEmapping b/MUON/READMEmapping deleted file mode 100644 index 3ffb8623133..00000000000 --- a/MUON/READMEmapping +++ /dev/null @@ -1,231 +0,0 @@ - $Id$ - - - The mapping package - ==================== - - See detailed description in ALICE-INT-2003-025. - - Graphical User Interface - ======================== - - To use the GUI to plot DE segmentation run: - - new AliMpDEVisu(); - or - - new AliMpDEVisu(w, h); - - if you want to change the size of the GUI window. - Typical value are: - w = 1200, h = 600 for PC - w = 1000, h = 550 for laptop - - The GUI allows: - - drawing motif of a slat/quadrant - - search of a given manu (motif) number - - draw the channel number for a given manu number by clicking of the motif in canvas - - write down in log message informations about the given detection element - * DE Id, DE name, - * number of buspatches, manus, manu serials - - option to save log message onto disc - - Test macros - ============ - cd ../mapping/macro - root - root [0] .x testMacroName.C - - see available macros below - - A set of test macros be run at once by test_suite.pl scripts: - test_suite.pl - run all test macros and compare results with - the reference output - test_suite_ref.pl - generates reference output - !! this script will overwrite the refence output - provided with the source; - it should be used only by developers - - Macros included in the test suite: - testReadSector.C - testReadMotifType.C - testGraphics.C - testSectorFind.C - testPlaneFind.C - testPrintLimits.C - testExistingPads.C - testPadDimensions.C - testSectorPadIterators.C - testMotifTypeIterators.C - testNeighboursPadIterator.C - testAnyPadIterators.C - testPadsUp.C - testPlaneAreaIterator.C - - Other macros (not included in the test suite): - testAllIndices.C - testUpdateGlobalIndices.C - - - Data files format - ================= - - zones.dat: - ------------- - Describes layout of zones, rows, row segments, subzones, motifs - - SECTOR_DATA - number of zones - number of rows - direction of constant pad size (X or Y) - offset in X direction - offset in Y direction - - ZONE - number of zone - half legth of pad size in x - half legth of pad size in y - - SUBZONE - motif id - motif type_id - - ROW_SEGMENT - x offset (in number of pads) - y offset (in number of pads) - row number - nof motifs - first motif position Id - step to the next motif position Id (+1 or -1) - - zones_special.dat: - ------------------ - Describes layout of special row segments (with irregular motifs) - - SECTOR_SPECIAL_DATA - - MOTIF - zone id - motif id - motif type_id - - ROW - row number - - PAD_ROWS - number of these pad rows in row - - PAD_ROW_SEGMENT - mumber of pads in the rows segment - motif id - motif position id - - motifX.dat - ---------- - Describes characteristics of the motif type X - - In lines: - Berg number - Kapton number - Pad number - Gassi number - - motifSpecialX.dat - ------------------ - Describes characteristics of the special motif with motif Id X; - the special motif caontains pads of different size - - In lines: - pad index i (in x) - pad index j (in y) - half legth of pad size in x - half legth of pad size in y - - padPosX.dat - ----------- - Maps pad numbers used in the motifX.dat files to - the local pad indices (i,j) - - In lines: - Pad number - pad index i (in x) - pad index j (in y) - - - *.pcb files - ============ - - Lines starting with # are comments. - - SIZES PadSizeX PadSizeY SizeX SizeY (cm) - - MOTIF motifType ix iy - MOTIF motifType ix iy - ... - - where ix, iy are the local coordinates (in pad unit) of the - lower-left corner of the motif (0,0 is the lower-left corner - of the PCB). - - PCB *MUST* be described in a rotating way, starting lower-left and - then counter-clockwise, otherwise the manu-to-motif association - (fixed in the slat definition files) will be wrong. - - Note that for "full" PCBs, the SizeX and SizeY are redundant as they could be - computed from the motif alone (but that serves as a cross-check that the motif - pattern given is ok). That's not the case for short or rounded PCB though. - - *.slat files - ============= - - A slat is defined by the list of its PCB, described starting - from the beam and going outward. - - One PCB per line, preceded by the keyword PCB - Other lines not matching this syntax are ignored. - After the PCB is the list of manu ids for this PCB. - - Example : - - PCB X 1-3;24-20;42;44;53 - PCB X 1-14 - PCB Y 100-90 - PCB Z 1;2;3;4;5;6;7;12;120 - - defines a slat with 4 PCBs : XXYZ - - The manu to motif relationship is attached to the fact that we're counting - counter-clockwise, starting on the lower-left of the PCB. (and the pcb files - have to follow this convention to defined their motifs, otherwise all - this won't work). - - Note that the definition of the PCBs have to be in files with extension - .pcb (X.pcb, Y.pcb, Z.pcb) - - - DetElemIdToBusPatch.dat - ======================= - Lines starting with # are comments. - - Contains the detection element identifier with the associated buspatch numbers - and the corresponding DDL identifier. - The link between buspatches and DE's is needed on the rawdata level to identify - the type of quadrant/slat to get the corresponding mapping. - The DDL id is needed for the rawdata generation only. - - To generate this file, the macro MUONGenerateBusPatch.C could be used. - - crate.dat - ========= - - Muon trigger electronics configuration file (decoded in class - AliMUONTriggerCrateStore) directly copy/paste from the ALICE PRR - ALICE-EN-2003-010. Gives local board number, name, - crate name it belongs to, slot number, and internal switches - (used in the algorithm). - - Units used - ============ - - Lengths are in centimeters. - - diff --git a/MUON/READMEmapping.txt b/MUON/READMEmapping.txt new file mode 100644 index 00000000000..239ed2341c3 --- /dev/null +++ b/MUON/READMEmapping.txt @@ -0,0 +1,255 @@ +// $Id$ + +/*! + +\page README_mapping README mapping + + +See detailed description in ALICE-INT-2003-025. + + +\section mapping_s1 Graphical User Interface + +To use the GUI to plot DE segmentation run: + +
+new AliMpDEVisu();
+
+ +or + +
+new AliMpDEVisu(w, h);
+
+ +if you want to change the size of the GUI window. +Typical value are: +
+  w = 1200, h = 600 for PC
+  w = 1000, h = 550 for laptop
+
+ +The GUI allows: +- drawing motif of a slat/quadrant +- search of a given manu (motif) number +- draw the channel number for a given manu number by clicking of the motif in canvas +- write down in log message informations about the given detection element + * DE Id, DE name, + * number of buspatches, manus, manu serials +- option to save log message onto disc + +\section mapping_s2 Test macros + +
+   cd ../mapping/macro
+   root
+   root [0] .x testMacroName.C    
+                      see available macros below   
+
+ +A set of test macros be run at once by test_suite.pl scripts: +- test_suite.pl - run all test macros and compare results with + the reference output +- test_suite_ref.pl - generates reference output + !! this script will overwrite the refence output + provided with the source; + it should be used only by developers + +Macros included in the test suite: +- testReadSector.C +- testReadMotifType.C +- testGraphics.C +- testSectorFind.C +- testPlaneFind.C +- testPrintLimits.C +- testExistingPads.C +- testPadDimensions.C +- testSectorPadIterators.C +- testMotifTypeIterators.C +- testNeighboursPadIterator.C +- testAnyPadIterators.C +- testPadsUp.C +- testPlaneAreaIterator.C + +Other macros (not included in the test suite): +- testAllIndices.C +- testUpdateGlobalIndices.C + + +\section mapping_s3 Data files format + + +\subsection mapping_s3_sub1 zones.dat: + +Describes layout of zones, rows, row segments, subzones, motifs + +
+  SECTOR_DATA
+    number of zones  
+    number of rows  
+    direction of constant pad size (X or Y)
+    offset in X direction
+    offset in Y direction
+  
+  ZONE     
+    number of zone  
+    half legth of pad size in x  
+    half legth of pad size in y
+
+  SUBZONE  
+    motif id  
+    motif type_id       
+
+  ROW_SEGMENT  
+    x offset (in number of pads) 
+    y offset (in number of pads) 
+    row number 
+    nof motifs 
+    first motif position Id
+    step to the next motif position Id (+1 or -1)
+
+ + +\subsection mapping_s3_sub2 zones_special.dat: + +Describes layout of special row segments (with irregular motifs) + +
+  SECTOR_SPECIAL_DATA
+
+  MOTIF
+    zone id
+    motif id  
+    motif type_id       
+
+  ROW
+    row number
+  
+  PAD_ROWS
+    number of these pad rows in row   
+  
+  PAD_ROW_SEGMENT
+    mumber of pads in the rows segment  
+    motif id  
+    motif position id
+  
+  motifX.dat
+  ----------
+  Describes characteristics of the motif type X
+
+  In lines:
+    Berg number
+    Kapton number
+    Pad number
+    Gassi number
+
+ + +\subsection mapping_s3_sub3 motifSpecialX.dat + +Describes characteristics of the special motif with motif Id X; +the special motif caontains pads of different size + +
+  In lines:
+    pad index i (in x)
+    pad index j (in y)
+    half legth of pad size in x  
+    half legth of pad size in y
+
+ +\subsection mapping_s3_sub4 padPosX.dat + +Maps pad numbers used in the motifX.dat files to +the local pad indices (i,j) + +
+  In lines:
+    Pad number
+    pad index i (in x)
+    pad index j (in y)
+
+ + +\subsection mapping_s3_sub4 *.pcb files + +Lines starting with # are comments. + +
+  SIZES PadSizeX PadSizeY SizeX SizeY (cm)
+
+  MOTIF motifType ix iy
+  MOTIF motifType ix iy
+  ...
+
+ +where ix, iy are the local coordinates (in pad unit) of the +lower-left corner of the motif (0,0 is the lower-left corner +of the PCB). + +PCB *MUST* be described in a rotating way, starting lower-left and +then counter-clockwise, otherwise the manu-to-motif association +(fixed in the slat definition files) will be wrong. + +Note that for "full" PCBs, the SizeX and SizeY are redundant as they could be +computed from the motif alone (but that serves as a cross-check that the motif +pattern given is ok). That's not the case for short or rounded PCB though. + + +\subsection mapping_s3_sub5 *.slat files + +A slat is defined by the list of its PCB, described starting +from the beam and going outward. + +One PCB per line, preceded by the keyword PCB +Other lines not matching this syntax are ignored. +After the PCB is the list of manu ids for this PCB. + +Example : + +
+  PCB X 1-3;24-20;42;44;53
+  PCB X 1-14
+  PCB Y 100-90
+  PCB Z 1;2;3;4;5;6;7;12;120
+
+ +defines a slat with 4 PCBs : XXYZ + +The manu to motif relationship is attached to the fact that we're counting +counter-clockwise, starting on the lower-left of the PCB. (and the pcb files +have to follow this convention to defined their motifs, otherwise all +this won't work). + +Note that the definition of the PCBs have to be in files with extension +.pcb (X.pcb, Y.pcb, Z.pcb) + + +\subsection mapping_s3_sub6 DetElemIdToBusPatch.dat + +Lines starting with # are comments. + +Contains the detection element identifier with the associated buspatch numbers +and the corresponding DDL identifier. +The link between buspatches and DE's is needed on the rawdata level to identify +the type of quadrant/slat to get the corresponding mapping. +The DDL id is needed for the rawdata generation only. + +To generate this file, the macro MUONGenerateBusPatch.C could be used. + + +\subsection mapping_s3_sub7 crate.dat + +Muon trigger electronics configuration file (decoded in class +AliMUONTriggerCrateStore) directly copy/paste from the ALICE PRR +ALICE-EN-2003-010. Gives local board number, name, +crate name it belongs to, slot number, and internal switches +(used in the algorithm). + + +\section mapping_s4 Units used + +Lengths are in centimeters. + +*/ + diff --git a/MUON/READMEraw b/MUON/READMEraw.txt similarity index 86% rename from MUON/READMEraw rename to MUON/READMEraw.txt index 38bbdd99dc7..fd95b0048c2 100644 --- a/MUON/READMEraw +++ b/MUON/READMEraw.txt @@ -1,26 +1,39 @@ -============================================================ - How to read & decode raw data -============================================================ +// $Id$ + +/*! + +\page README_raw README raw + +\section raw_s1 How to read & decode raw data + These macros can read & decode DDL files, root and DATE files. Nevertheless for the two latter, aliroot has to be compiled with DATE. For tracker raw data +
 .includepath $ALICE_ROOT/STEER
 .includepath $ALICE_ROOT/MUON
 .includepath $ALICE_ROOT/RAW
 .L $ALICE_ROOT/MUON/MUONRawStreamTracker.C+
 MUONRawStreamTracker(maxEvent, firstDDL, lastDDL, rawFileName)
+
For trigger raw data +
 .includepath $ALICE_ROOT/STEER
 .includepath $ALICE_ROOT/MUON
 .includepath $ALICE_ROOT/RAW
 .L $ALICE_ROOT/MUON/MUONRawStreamTrigger.C+ 
 MUONRawStreamTrigger(maxEvent, firstDDL, lastDDL, rawFileName)
+
Default wise the macro read all DDL files from the current directory for 1000 events. For root file rawFileName must end with .root, for date file rawFileName must be no extention. For DDL files you have to specified the directory where the raw0...n subdirectories are located: +
 MUONRawStreamTracker(maxEvent, "$YOUR_WORKING_DIRECTORY/"); //Do not forget the slash at the end!
+
+ +*/ diff --git a/MUON/READMEshuttle b/MUON/READMEshuttle.txt similarity index 95% rename from MUON/READMEshuttle rename to MUON/READMEshuttle.txt index b969b76fc67..7c11ffe8d4b 100644 --- a/MUON/READMEshuttle +++ b/MUON/READMEshuttle.txt @@ -1,4 +1,8 @@ -$Id$ +// $Id$ + +/*! + +\page README_shuttle README shuttle How to test the Shuttle preprocessor(s) for MUON. @@ -11,23 +15,22 @@ Depending on the subsystem and on the task to be performed (based on the run typ Output of most processors will end up in OCDB (Offine Condition DataBase). A set of helper functions to peek at this OCDB are gathered in AiMUONCDB class. -------- -TestMUONPreprocessor.C -------- + +\section shuttle_s1 TestMUONPreprocessor.C This is the master macro used to check the MUON part of the Shuttle. Depending on what you want to test, you'll have to modify the input files (using shuttle->AddInputFile) and/or the run type (using shuttle->AddInputRunParameter()) -------- -AliMUONPreprocessor(const TString& detName) -------- + +\section shuttle_s2 AliMUONPreprocessor(const TString& detName) Depending on how this one is constructed, and depending on the runtype, it will perform differents tasks. Note that for the moment the runtypes are "fake", i.e. put by hand in the TestMUONPreprocessor.C macro, and might not correspond to the final values to be used by the DAQ. - + +
 
 detName   runType                     task to be done           worker class (AliMUONVSubprocessor child)
 --------------------------------------------------------------------------------------------------------
 MCH       PEDESTAL_RUN                read ASCII ped files      AliMUONPedestalSubprocessor
@@ -43,10 +46,10 @@ MCH       ELECTRONICS_CALIBRATION_RUN read ASCII gain files     prototype only =
                                       and put them into OCDB
                                       
 MTR       to be defined               to be defined             to be done
+
----------- -Pedestals ----------- + +\section shuttle_s3 Pedestals Two options here. You can either use a pre-done set of ASCII pedestals files (generated as explained below for the 2nd option), located at /afs/cern.ch/user/l/laphecet/public/LDC*.ped, @@ -58,15 +61,18 @@ using the WritePedestals() method of AliMUONCDB class So first generate a valid pedestal CDB entry by using the AliMUONCDB class +
 root[] const char* cdbpath="local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB"; // where to put the CDB
 root[] AliMUONCDB cdb(cdbpath)
 root[] Bool_t defaultValues = kFALSE; // to generate random values instead of plain zeros...
 root[] Int_t startRun = 80;
 root[] Int_t endRun = 80;
 root[] cdb.WritePedestals(defaultValues, startRun, endRun);
+
Expected output is (don't worry about the warnings, they are harmless) : +
 I-AliMUONCDB::ManuList: Generating ManuList...
 I-AliMUONCDB::ManuList: Manu List generated.
 I-AliMUONCDB::MakePedestalStore: 16828 Manus and 1064008 channels.
@@ -74,10 +80,12 @@ I-AliMUONCDB::WritePedestals: Ngenerated = 1064008
 I-AliCDBManager::Init: AliEn classes enabled in Root. AliCDBGrid factory registered.
 I-AliCDBManager::SetDefaultStorage: Setting Default storage to: local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB
 I-AliCDBLocal::PutEntry: CDB object stored into file ($ALICE_ROOT)/SHUTTLE/TestShuttle/TestCDB/MUON/Calib/Pedestals/Run80_80_v0_s0.root
+
Then use the AliMUONPedestalEventGenerator to produce simulated pedestal events. Usage (from the Root prompt) : +
 AliCDBManager::Instance()->SetDefaultStorage(cdbpath); // so you will read 
 // back pedestals values generated in the previous step
 const char* dateFileName = "raw.date"; // base filename for the output
@@ -86,6 +94,7 @@ Int_t nevents = 100; // # of events to generate. 100 should be enough
 gSystem->Load("libMUONshuttle"); // needed or not depending on whether it's already loaded or not
 AliMUONPedestalEventGenerator ped(runNumber,nevents,dateFileName);
 ped.Exec("");
+
It *will* take a lot of time (mainly due to the fact that we're writing a bunch of ASCII files = DDL files), so please be patient. @@ -102,9 +111,11 @@ The raw.date.LDC* files are then processed using the makeped online program under /afs/cern.ch/user/a/abaldiss/public/v16; Please contact Alberto to check it's the latest version) which outputs manus-*.ped ASCII files (one per LDC) : +
  makeped -f raw.date.LCDi -a LDCi.ped (i=0,1,2,3)
  
  (repeat for each LDC)
+
The LDCi.ped files are the input for the pedestal subprocessor, which is tested using the TestMUONPreprocessor.C macro. @@ -112,9 +123,8 @@ The output of the pedestal subprocessor (upon success only) is written into the Difference between the input and the output can be inferred using the diff() function of MUONCDB.C macro. ----------- -Gains ----------- + +\section shuttle_s4 Gains Like pedestals, you have two options here. You can either use a pre-done set of ASCII gain files (generated as explained below for the 2nd option), @@ -128,6 +138,7 @@ The pedestal and gain values are taken from the Offline Condition DataBase (OCDB So first you need to generate a valid pedestal CDB entry and a valid gain CDB entry by using the AliMUONCDB class, from the Root prompt: +
 const char* cdbpath="local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB"; // where to put the CDB
 AliMUONCDB cdb(cdbpath)
 Bool_t defaultValues = kFALSE; // to generate random values instead of plain zeros...
@@ -135,6 +146,7 @@ Int_t gainRun = 80;
 Int_t pedRun = 81;
 cdb.WritePedestals(defaultValues, pedRun, pedRun);
 cdb.WriteGains(defaultValues, gainRun, gainRun);
+
Expected output is (don't worry about the warnings, they are harmless) : @@ -144,6 +156,7 @@ will be n x 4 date files (n is the number of fake injections, currently 9, and 4 Usage (again, from the Root prompt) : +
 const char* cdbpath="local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB"; // where to get the CDB
 AliCDBManager::Instance()->SetDefaultStorage(cdbpath); // so you will read 
 // back pedestals and gain values generated in the previous step
@@ -155,6 +168,7 @@ Int_t nevents = 100; // # of events to generate. 100 should be enough for testin
 gSystem->Load("libMUONshuttle"); // needed or not depending on whether it's already loaded or not
 AliMUONGainEventGenerator g(gainRunNumber,pedRunNumber,nevents,dateFileName);
 g.Exec("");
+
It *will* take a lot of time (mainly due to the fact that we're writing a bunch of ASCII files = DDL files), so please be patient. @@ -164,25 +178,27 @@ containing the normal simulated sequence of MUON.Hits.root, MUON.SDigits.root, MUON.Digits.root, raw/*.ddl files and raw.date.LDCi where i=0-3 (i.e. one DATE file per LDC, as will be used in real life), the latter ones being roughly 100 MB each. +
 // FIXME
 // Below should follow instructions on how to feed the MUONTRKda with the
 // generated files.
+
+ -------- -HV -------- +\section shuttle_s5 HV HV DCS values are created in CreateDCSAliasMap() of TestMUONPreprocessor.C You might want to modify this function to create a given set of error conditions in order to test whether the HVSubprocessor is reacting properly to those errors. -------- -GMS -------- + +\section shuttle_s6 GMS The GMS alignment data for testing can be generated with the macro MUONGenerateTestGMS.C: The matrices of TGeoHMatrix type, with TObject::fUniqueID equal to the geometry module Id, are put in a TClonesArray and saved in the Root file with a key "GMSarray". + +*/ diff --git a/MUON/READMEtrigger b/MUON/READMEtrigger.txt similarity index 67% rename from MUON/READMEtrigger rename to MUON/READMEtrigger.txt index 66cf6afd3d2..65c69eb2f29 100644 --- a/MUON/READMEtrigger +++ b/MUON/READMEtrigger.txt @@ -1,23 +1,31 @@ +// $Id$ + +/*! + +\page README_trigger README trigger + + +\section trigger_s1 How to reprocess trigger decision from already produced digits -=========================================================== - How to reprocess trigger decision from already produced digits -=========================================================== The MUONTrigger.C macro can be used to check the trigger algorithm w/o having to (re-)perform simulation and digitalization. It loads the digits, erase TreeR and store the current trigger output in TreeR. + The different trigger outputs can be compared by looking at the GLT branch of TreeD (filled during simulation) and the TC branch of TreeR (filled from a copy of TreeD during reconstruction or with this macro). Note: rec points from tracking chamber will be lost. + Usage: +
 root [0] .L $ALICE_ROOT/MUON/MUONTrigger.C+
 root [1] MUONTrigger()
+
+ +\section trigger_s2 OFFLINE trigger GUI data quality and debugging tool -=========================================================== -OFFLINE trigger GUI data quality and debugging tool -=========================================================== - read digits and local trigger decision from simulated/real data - display - reprocess trigger decision inside AliRoot @@ -25,83 +33,73 @@ OFFLINE trigger GUI data quality and debugging tool TriggerElectronics, execute trigger algorithm and recover the local trigger decision -Classes: *TriggerGUI* - -Library: evaluation - -Run ---- +To run: +
 aliroot
 new AliMUONTriggerGUI()
+
-Main window ------------ - -"Map of the local boards as seen from the I.P." - -the main window is position sensitive (after file initialization) and it is +Main window shows the map of the local boards as seen from the I.P. +The main window is position sensitive (after file initialization) and it is possible to open a GUI for a circuit. By menus: -File ----- -Run - open a file and start with a given event number - takes the full path /galice.root +\subsection trigger_s2_sub1 File -Control - navigate in the tree with events +- Run - open a file and start with a given event number + takes the full path /galice.root +- Control - navigate in the tree with events +- Exit - exit the main application -Exit - exit the main application -Maps ----- +\subsection trigger_s2_sub2 Maps -Digits map - graphical map with digits in the four chambers, MT11 ... MT22 +- Digits map - graphical map with digits in the four chambers, MT11 ... MT22 -Chambers digit maps window --------------------------- +\subsection trigger_s2_sub3 Chambers digit maps window -Update - update the map after: +- Update - update the map after: - loading of another event - changing interactively the strip signals in boards GUI -Circuit -------- -Open - open a board GUI by circuit number +\subsection trigger_s2_sub4 Circuit + +- Open - open a board GUI by circuit number -Trigger -------- -Trigger DSET - (re)run the trigger algorithm +\subsection trigger_s2_sub5 Trigger -Circuit GUI window ------------------- +- Trigger DSET - (re)run the trigger algorithm + + +\subsection trigger_s2_sub6 Circuit GUI window - visualize x/y strips - "Set/unset" x (or) y strips - "Digits" create board digits from the actual configuration created in the GUI - "Reset" reset modification on strips done interactively -Bogdan Vulpescu -vulpescu@clermont.in2p3.fr -1 June 2007 +\section trigger_s3 How to check integrated trigger efficiency -=========================================================== - How to check integrated trigger efficiency -=========================================================== The MUONTriggerEfficiency.C macro (included in the check scripts) calculates the trigger efficiency for the 2 pt cuts. The output is stored in MUONTriggerEfficiency.out file. + Usage: +
 root [0] .L $ALICE_ROOT/MUON/MUONTriggerEfficiency.C+
 root [1] MUONTriggerEfficiency()
+
+ For the CVS default version of the trigger LUT (i.e. lutAptLpt1Hpt1p7.root), The reference for J/psi and Upsilon is as below For 1000 Jpsi events with: +
     AliGenParam *gener = new AliGenParam(1, AliGenMUONlib::kJpsi);
     gener->SetMomentumRange(0,999);
     gener->SetPtRange(0,100.);
@@ -112,20 +110,29 @@ The reference for J/psi and Upsilon is as below
     gener->SetOrigin(0,0,0);          
     gener->SetForceDecay(kDiMuon);
     gener->SetTrackingFlag(1);
+
+ the output should be +
   Efficiency Lpt cut = 0.7362 +/- 0.0391
   Efficiency Hpt cut = 0.2662 +/- 0.0201
+
+ Similarly, for 1000 Upsilon events, the output should be + +
   Efficiency Lpt cut = 0.9806 +/- 0.0457
   Efficiency Hpt cut = 0.9537 +/- 0.0448
+
+ + +\section trigger_s4 How to check single muon trigger efficiency versus pt -=========================================================== - How to check single muon trigger efficiency versus pt -=========================================================== The MUONTriggerEfficiencyPt.C macro produces trigger single muon efficiency versus pt plots for the 2 pt cuts. Results are compared to the reference (red curves). To be used with (at least) 10000 events as follows +
    AliGenBox * gener = new AliGenBox(1);
    gener->SetPtRange(0.,10.);
    gener->SetPhiRange(0., 360.);         
@@ -133,29 +140,44 @@ To be used with (at least) 10000 events as follows
    gener->SetPart(13);           // or -13
    gener->SetOrigin(0.,0., 0.);  
    gener->SetSigma(0.0, 0.0, 0.0);     
+
+ Outputs are stored in MUONTriggerEfficiencyPt.gif/eps/out files Important note: this macro works with one (real) muon track per event only + Usage: +
 root [0] .L $ALICE_ROOT/MUON/MUONTriggerEfficiencyPt.C+
 root [1] MUONTriggerEfficiencyPt()
+
+ + +\section trigger_s5 How to get trigger chamber efficiency from data -=========================================================== - How to get trigger chamber efficiency from data -=========================================================== Trigger chamber efficiency map is calculated during reconstruction and saved in AliESDs.root In order to view and save the map, use macro MUONTriggerChamberEfficiency.C To compile MUONTriggerChamberEfficiency.C +
 .includepath $ALICE_ROOT/MUON
 .L $ALICE_ROOT/MUON/MUONTriggerChamberEfficiency.C+
+
-// To run MUONTriggerChamberEfficiency.C +To run MUONTriggerChamberEfficiency.C +
 MUONTriggerChamberEfficiency();
+
-//If you want to make the calculated map available for next simulation use option kTRUE, i.e. +If you want to make the calculated map available for next simulation use option kTRUE, i.e. +
 MUONTriggerChamberEfficiency(kTRUE);
+
When running next simulation, please remember to activate trigger efficiency by adding in Config.C: +
 MUON->SetTriggerEffCells(1);
+
+ +*/ -- 2.39.3