-$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 :
+<pre>
$ALICE_ROOT/MUON/AlirootRun_MUONtest.sh [option]
+</pre>
The complete list of the option is printed when you call
the script with whatever non valid option, .eg. h:
+<pre>
./AlirootRun_MUONtest.sh h
ERROR : extra option not recognized
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)
+</pre>
The results of this test are saved in test_out.nevent directory.
Please note that the CDB (Condition DataBase) is now always *required*
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).
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 :
+<pre>
$ALICE_ROOT/MUON/AlirootRun_MUONtestlong.sh
+</pre>
The results of this test are saved in testlong_out/ directory
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 :
+<pre>
> 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
+</pre>
for all other information, use AliMUONDataInterface :
+<pre>
> 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
+</pre>
Remind that during simulation and reconstruction two
differents galice.root are generated: one for the generation
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
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
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:
+<pre>
AliMagFMaps* field = new AliMagFMaps("Maps","Maps", TRACKING, FACTOR, MAXB, AliMagFMaps::k5kG);
gAlice->SetField(field);
+</pre>
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.
- *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
which tell us what is the biais source.
Enclose an example to use this generator:
+<pre>
AliGenMUONCocktail * gener = new AliGenMUONCocktail();
gener->SetPtRange(1.,100.); // Transverse momentum range
gener->SetPhiRange(0.,360.); // Azimuthal angle range
gener->SetOrigin(0,0,0); // Vertex position
gener->SetSigma(0,0,0.0); // Sigma in (X,Y,Z) (cm) on IP position
gener->Init();
+</pre>
-==========================================================
-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
before instantiating AliSimulation (see for example the commented
lines AlirootRun_MUONtest.sh).
+<pre>
aliroot -b >& testSim.out << EOF
AliCDBManager* man = AliCDBManager::Instance();
man->SetDefaultStorage("local://$ALICE_ROOT");
MuonSim.Run(10);
.q
EOF
+</pre>
-
-==========================================================
- 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
Hijing simulation
+<pre>
aliroot -b << EOF
AliSimulation HijingSim("$HIJING_SIM/YourConfigForHIJING.C")
HijingSim.Run(5)
.q
EOF
+</pre>
You cand build YourConfigFroHIJING.C File from the
ConfigPPR file in AliRoot/macros module.
merging 20 times each Hijing event in order to simulate
100 muons merged with 5 Hijing events.
-
+<pre>
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
MuonRec.Run()
.q
EOF
+</pre>
-==========================================================
-...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
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:
+<pre>
for (Int_t itr = 0; itr < ntracks; itr++) {
AliMUONVHitStore* hitStore = mcDataInterface.HitStore(event,itr);
//track "itr" of the hits-tree
TParticle* particle = mcDataInterface.Stack(event)->Particle(id);
}
}
+</pre>
where mcDataInterface has been obtained by
AliMUONMCDataInterface mcDataInterface("galice.root");
that deposited a given digit one has to follow the sequence of the kind:
(shown here using the simple, but not fast, DataInterface interfaces) :
+<pre>
AliMUONMCDataInterface mcdi("galice.root");
AliMUONDataInterface di("galice.root");
Int_t idTrack = mHit->Particle(); //gives flavour code of the particle
}
}
+</pre>
-===========================================================
- 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.
+<pre>
Usage:
root [0] .L $ALICE_ROOT/MUON/MUONmassPlot_ESD.C+
root [1] MUONmassPlot_ESD(ExtrapToVertex,
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
+</pre>
+\section s13 Still working ..............
-
-===========================================================
- Still working ..............
-===========================================================
+*/
-$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
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
(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).
the Root prompt (from within the $ALICE_ROOT/MUON directory to get the correct
list of libraries loaded by the loadlibs.C macro)
+<pre>
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);
+</pre>
+
-------
-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 :
+<pre>
AliCDBManager::Instance()->SetDefaultStorage(cdbPath);
AliMUONCalibrationData cd(4567);
AliMUONV2DStore* ped = cd.Pedestals();
+</pre>
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.
+<pre>
AliMUONCDB cdb(cdbpath);
cdb.Plot(*ped,"pedestal")
+</pre>
which will create 2 histograms : pedestal_0 (mean) and pedestal_1 (sigma).
which generates an AliMUONV2DStore containing the difference
(either absolute or relative) of two AliMUONV2DStore.
+*/
-============================================================
- 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)
track identification is needed.
To compile MUONRecoCheck.C
+<pre>
.includepath $ALICE_ROOT/STEER
.includepath $ALICE_ROOT/MUON
.L $ALICE_ROOT/MUON/MUONRecoCheck.C+
+</pre>
-// To run MUONRecoCheck
+To run MUONRecoCheck
+<pre>
MUONRecoCheck(nEvent,"geometry.root", "galice.root"); // nEvent = nb of events
+</pre>
-==========================================================
-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.
with a tree of AliMUONTrackLight / AliMUONPairLight :
go to the directory containing the generation/reconstruction. From there run
aliroot
+
+<pre>
.L DecodeRecoCocktail.C+
DecodeRecoCocktail();
.q
+</pre>
To read the file previously generated:
+<pre>
aliroot
.L ReadRecoCocktail.C+
ReadRecoCocktail();
.q
+</pre>
+
+*/
-$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:
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
Both macros can be run from fastSim.sh test script.
+*/
+
- $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.
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
-============================================================
+<pre>
gAlice->Init("$ALICE_ROOT/MUON/Config.C");
gGeoManager->GetMasterVolume()->Draw();
+</pre>
+
+
+\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
-============================================================
+<pre>
gAlice->Init("$ALICE_ROOT/MUON/Config.C");
gGeoManager->CheckOverlaps();
gGeoManager->PrintOverlaps();
+</pre>
-
-===========================================================
- Macro MUONGenerateGeometryData.C
-===========================================================
+\section geometry_s4 Macro MUONGenerateGeometryData.C
Macro for generating the geometry data files
MUONGenerateGeometryData.C
To be run from aliroot:
+<pre>
.x MUONGenerateGeometryData.C
+</pre>
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:
+<pre>
.x MakeMUONFullMisAlignment.C etc.
+</pre>
If the environment variable TOCDB is not set to "kTRUE",
the misalignment data are generated in a local file:
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:
- Run the alignment code over the above events using MUONAlignment.C
To run you need to type:
+<pre>
$ALICE_ROOT/MUON/AlirootRun_MUONtestAlign.sh
+</pre>
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
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:
+<pre>
+ 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
+</pre>
+
+\subsection geometry_s2_sub2 svmap.dat
+
+ Map of sensitive volumes to detction element Ids;
+ in format:
+
+<pre>
+ KEY volpath detElemId
+
+ where KEY = SV
+ volpath = volume path in format /volname1_copyNo1/volname2_copyNo2/...
+ detElemId = detection element Id
+ </pre>
+
+
+*/
+++ /dev/null
- $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.
-
-
--- /dev/null
+// $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:
+
+<pre>
+new AliMpDEVisu();
+</pre>
+
+or
+
+<pre>
+new AliMpDEVisu(w, h);
+</pre>
+
+if you want to change the size of the GUI window.
+Typical value are:
+<pre>
+ w = 1200, h = 600 for PC
+ w = 1000, h = 550 for laptop
+</pre>
+
+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
+
+<pre>
+ cd ../mapping/macro
+ root
+ root [0] .x testMacroName.C
+ see available macros below
+</pre>
+
+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
+
+<pre>
+ 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)
+</pre>
+
+
+\subsection mapping_s3_sub2 zones_special.dat:
+
+Describes layout of special row segments (with irregular motifs)
+
+<pre>
+ 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
+</pre>
+
+
+\subsection mapping_s3_sub3 motifSpecialX.dat
+
+Describes characteristics of the special motif with motif Id X;
+the special motif caontains pads of different size
+
+<pre>
+ 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
+</pre>
+
+\subsection mapping_s3_sub4 padPosX.dat
+
+Maps pad numbers used in the motifX.dat files to
+the local pad indices (i,j)
+
+<pre>
+ In lines:
+ Pad number
+ pad index i (in x)
+ pad index j (in y)
+</pre>
+
+
+\subsection mapping_s3_sub4 *.pcb files
+
+Lines starting with # are comments.
+
+<pre>
+ SIZES PadSizeX PadSizeY SizeX SizeY (cm)
+
+ MOTIF motifType ix iy
+ MOTIF motifType ix iy
+ ...
+</pre>
+
+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 :
+
+<pre>
+ 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
+</pre>
+
+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.
+
+*/
+
-============================================================
- 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
+<pre>
.includepath $ALICE_ROOT/STEER
.includepath $ALICE_ROOT/MUON
.includepath $ALICE_ROOT/RAW
.L $ALICE_ROOT/MUON/MUONRawStreamTracker.C+
MUONRawStreamTracker(maxEvent, firstDDL, lastDDL, rawFileName)
+</pre>
For trigger raw data
+<pre>
.includepath $ALICE_ROOT/STEER
.includepath $ALICE_ROOT/MUON
.includepath $ALICE_ROOT/RAW
.L $ALICE_ROOT/MUON/MUONRawStreamTrigger.C+
MUONRawStreamTrigger(maxEvent, firstDDL, lastDDL, rawFileName)
+</pre>
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:
+<pre>
MUONRawStreamTracker(maxEvent, "$YOUR_WORKING_DIRECTORY/"); //Do not forget the slash at the end!
+</pre>
+
+*/
-$Id$
+// $Id$
+
+/*!
+
+\page README_shuttle README shuttle
How to test the Shuttle preprocessor(s) for MUON.
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.
-
+
+<pre>
detName runType task to be done worker class (AliMUONVSubprocessor child)
--------------------------------------------------------------------------------------------------------
MCH PEDESTAL_RUN read ASCII ped files AliMUONPedestalSubprocessor
and put them into OCDB
MTR to be defined to be defined to be done
+</pre>
-----------
-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,
So first generate a valid pedestal CDB entry by using the AliMUONCDB class
+<pre>
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);
+</pre>
Expected output is (don't worry about the warnings, they are harmless) :
+<pre>
I-AliMUONCDB::ManuList: Generating ManuList...
I-AliMUONCDB::ManuList: Manu List generated.
I-AliMUONCDB::MakePedestalStore: 16828 Manus and 1064008 channels.
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
+</pre>
Then use the AliMUONPedestalEventGenerator to produce simulated pedestal events.
Usage (from the Root prompt) :
+<pre>
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
gSystem->Load("libMUONshuttle"); // needed or not depending on whether it's already loaded or not
AliMUONPedestalEventGenerator ped(runNumber,nevents,dateFileName);
ped.Exec("");
+</pre>
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.
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) :
+<pre>
makeped -f raw.date.LCDi -a LDCi.ped (i=0,1,2,3)
(repeat for each LDC)
+</pre>
The LDCi.ped files are the input for the pedestal subprocessor,
which is tested using the TestMUONPreprocessor.C macro.
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),
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:
+<pre>
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...
Int_t pedRun = 81;
cdb.WritePedestals(defaultValues, pedRun, pedRun);
cdb.WriteGains(defaultValues, gainRun, gainRun);
+</pre>
Expected output is (don't worry about the warnings, they are harmless) :
Usage (again, from the Root prompt) :
+<pre>
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
gSystem->Load("libMUONshuttle"); // needed or not depending on whether it's already loaded or not
AliMUONGainEventGenerator g(gainRunNumber,pedRunNumber,nevents,dateFileName);
g.Exec("");
+</pre>
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.
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.
+<pre>
// FIXME
// Below should follow instructions on how to feed the MUONTRKda with the
// generated files.
+</pre>
+
--------
-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".
+
+*/
+// $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:
+<pre>
root [0] .L $ALICE_ROOT/MUON/MUONTrigger.C+
root [1] MUONTrigger()
+</pre>
+
+\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
TriggerElectronics, execute trigger algorithm and recover the local trigger
decision
-Classes: *TriggerGUI*
-
-Library: evaluation
-
-Run
----
+To run:
+<pre>
aliroot
new AliMUONTriggerGUI()
+</pre>
-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 <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 <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:
+<pre>
root [0] .L $ALICE_ROOT/MUON/MUONTriggerEfficiency.C+
root [1] MUONTriggerEfficiency()
+</pre>
+
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:
+<pre>
AliGenParam *gener = new AliGenParam(1, AliGenMUONlib::kJpsi);
gener->SetMomentumRange(0,999);
gener->SetPtRange(0,100.);
gener->SetOrigin(0,0,0);
gener->SetForceDecay(kDiMuon);
gener->SetTrackingFlag(1);
+</pre>
+
the output should be
+<pre>
Efficiency Lpt cut = 0.7362 +/- 0.0391
Efficiency Hpt cut = 0.2662 +/- 0.0201
+</pre>
+
Similarly, for 1000 Upsilon events, the output should be
+
+<pre>
Efficiency Lpt cut = 0.9806 +/- 0.0457
Efficiency Hpt cut = 0.9537 +/- 0.0448
+</pre>
+
+
+\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
+<pre>
AliGenBox * gener = new AliGenBox(1);
gener->SetPtRange(0.,10.);
gener->SetPhiRange(0., 360.);
gener->SetPart(13); // or -13
gener->SetOrigin(0.,0., 0.);
gener->SetSigma(0.0, 0.0, 0.0);
+</pre>
+
Outputs are stored in MUONTriggerEfficiencyPt.gif/eps/out files
Important note: this macro works with one (real) muon track per event only
+
Usage:
+<pre>
root [0] .L $ALICE_ROOT/MUON/MUONTriggerEfficiencyPt.C+
root [1] MUONTriggerEfficiencyPt()
+</pre>
+
+
+\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
+<pre>
.includepath $ALICE_ROOT/MUON
.L $ALICE_ROOT/MUON/MUONTriggerChamberEfficiency.C+
+</pre>
-// To run MUONTriggerChamberEfficiency.C
+To run MUONTriggerChamberEfficiency.C
+<pre>
MUONTriggerChamberEfficiency();
+</pre>
-//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.
+<pre>
MUONTriggerChamberEfficiency(kTRUE);
+</pre>
When running next simulation, please remember to activate trigger efficiency
by adding in Config.C:
+<pre>
MUON->SetTriggerEffCells(1);
+</pre>
+
+*/
git://git.uio.no / u / mrichter / AliRoot.git / commitdiff