- Macro to get the trigger chamber efficiency map from reconstruction and

[u/mrichter/AliRoot.git] / MUON / README

$Id$

==========================================================
Please add  to this README file all information concerning 
config files, simulation, digitalization, clusterization, 
reconstruction and macro analysis

==========================================================
 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 :
source $ALICE_ROOT/MUON/AlirootRun_MUONtest.sh 
The results of this test are saved in test_out/ directory.
Please note that the CDB (Condition DataBase) is now always *required* 
to perform either simulation or reconstruction. For the moment, a version
 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
==========================================================
There is a script file AlirootRun_MUONlongtest.sh which
allows for simulating, reconstructing and making the
-+invariant analysis of the generated Upsilon (1S).
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

(NOTE: the macros performing the calculations/plots MUONefficiency.C 
and MUONplotEfficiency.C are also able to handle J/Psi if 
Config.C is modified accordingly )

==========================================================
 How to run a MUON generation
==========================================================
aliroot
root [0] gAlice->Run(10,"$ALICE_ROOT/MUON/Config.C");

1 single muon of 7 GeV/c in the MUON spectrometer 
acceptance will be simulated using geant3. 
Hit information will be store in the root file in the
execution directory.
If you want to change the option or to define a new directory
for hits, you have to do the following before:
root [0] gAlice->SetConfigFunction("Config( \"/home/martinez/aliroot/work_NewIO/test/\" , \"box\" );"); 

============================================================
 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

============================================================
 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();


============================================================
 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();

============================================================
 How to run MUONdisplay
============================================================
First you need to perform a full simulation: 
generation, digitalisation and clusterisation
To run MUONdisplay with Root 5.04/00 you need to get a fix in
the gpad/src/TPad.cxx from Root CVS:
 cvs update -r 1.200 gpad/src/TPad.cxx
and recompile root. 

.L $ALICE_ROOT/MUON/MUONdisplay.C
MUONdisplay(0,"galice.root")

============================================================
 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 
of the tracking chambers. The CUT's and physics processes of
the gas mixture medium  is then defined in the galice.cuts file
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
============================================================
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 
field is small. 
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

===========================================================
 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 
the muon sources: J/Psi, Upsilon, Open Charm, Open Beauty, 
Pion, Kaons. The code needs only the production cross section 
at 4pi (for the moment this values are in the code since I 
prefere them do not be modified), and the code calculates the  
rate of particles in the acceptance, making the scaling based 
on the number of collisions for the hard probes and on the  
number of participants for soft sources: Pions and Kaons.

In the Genereate of this class all entries in the cocktail 
are called and we define a "primordial trigger" with requires 
a minimum number of muons above a Pt cut in the required acceptance.
In order to normalized to the real number of simulated events, 
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 
gener->SetYRange(-4.0,-2.4);
gener->SetMuonPtCut(1.);
gener->SetMuonThetaCut(171.,178.);
gener->SetMuonMultiplicity(2);
gener->SetImpactParameterRange(0.,5.); // 10% most centra PbPb collisions
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();
 
================================================================
 csh Script for the full reconstruction with raw data generator
================================================================
The rawdata generation and analysis is working with the new segmentation.
So the config file must use the version "AliMUONFactoryV3"

Generation
The method AliSimulation::SetWriteRawData("MUON") enables on 
the muon rawdata generation
aliroot -b << EOF  
AliSimulation MuonSim("$ALICE_ROOT/MUON/Config.C")
MuonSim.SetMakeTrigger("MUON");
MuonSim.SetWriteRawData("MUON")
MuonSim.Run(10)
.q
EOF

Reconstruction
aliroot -b << EOF 
AliReconstruction MuonRec("galice.root");
MuonRec.SetInput("$YOUR_WORKING_DIRECTORY/");  Do not forget the slash at the end!
MuonRec.SetRunVertexFinder(kFALSE);
MuonRec.SetRunLocalReconstruction("MUON");
MuonRec.SetRunTracking("");
MuonRec.SetFillESD("MUON");
MuonRec.SetOption("MUON", "VS"); // to use VS cluster finder
// MuonRec.SetOption("MUON", "VS Original"); // to run VS and original track finder
// MuonRec.SetOption("MUON", "Combi"); // to run combined cluster / track finder
MMuonRec.Run();
.q
EOF

============================================================
 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!


============================================================
 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)
and kinematic informations (TreeK) for the vertex.
This macro can be used to check the track reconstruction e.g. efficiency,
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
MUONRecoCheck(nEvent,"geometry.root", "galice.root"); // nEvent = nb of events


============================================================
 How to run MUONTracker macro
============================================================
To make the track reconstruction directly from AliTrackReference hits 
which are recorded in TrackRefs.root during the simulation.
It can be used to check the reconstruction without clusterization.	

To compile MUONTracker.C
.includepath $ALICE_ROOT/STEER
.includepath $ALICE_ROOT/MUON
.L $ALICE_ROOT/MUON/MUONTracker.C+

// To run MUONTracker
MUONTracker(iEventMin,iEventMax,"galice.root"); // iEventMin: first event

===========================================================
 Macro  MUONGenerateGeometryData.C
===========================================================
						
Macro for generating the geometry data files

Geometry data files:
- MUON/data/volpath.dat file contains the volume paths 
for all alignable objects (modules & detection 
elements).
- MUON/data/transform.dat file contains the transformations
data (translation and rotation) for all alignable objects
(modules & detection elements)
- MUON/data/svmap.dat file contains all the information to link 
each geant volume (it can be extended to other virtual MC) with
a detection element. The point here is that a given detection
element, i.e. a slat chamber can consist of more geant volumes.
the correspondence is then defined in an input file.
Each time there is a change in the definition of MC geometry, these
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
===========================================================
						
Macro 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:
(MUONFullMisalignment.root, etc.)

If the data are stored in CDB, the storage can be specified in 
the environment variable STORAGE. The misalignment data are then
generated in the CDB folder (defaults are ResMisAlignCDB and FullMisAlignCDB
in the working directory). Inside the local CDB the path for the
alignment data is (and must be) "MUON/Align/Data/".
Residual misalignment: Default is our current estimate of
misalignment after all our alignment procedure has been applied.
Full misalignment: Default is our current estimate of initial
misalignment.

==========================================================
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
the next steps:

- Generate misaligned data in local CDB.
You can use MUONGenerateGeometryData.C as described above in
the corresponding section. Let's assume you used the default
residual misalignment settings, then you have a local CDB in
your working directory called ResMisAlignCDB containing
misalignement data (ResMisAlignCDB/MUON/Align).

- Tell AliSimulation you want to use your local CDB for 
MUON/Align/Data
To do this you need to instantiate the AliCDBManager, set the
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");
man->SetSpecificStorage("MUON/align/Data","local://ResMisAlignCDB");
AliSimulation MuonSim("$ALICE_ROOT/MUON/Config.C");
MuonSim.SetWriteRawData("MUON");
MuonSim.Run(10);
.q
EOF

==========================================================
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:
- Generate a misaligned geometry in a local CDB (default FullMisAlignCDB)
- Simulate 1000 events using previously misaligned geometry
- Reconstruct the events using perfect geometry
- 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
containing the realigned geometry is also created (default is ReAlignCDB). The
file $ALICE_ROOT/MUON/data/transform2ReAlign.dat contains the
transformations describing the realigned geometry to be compared with the
used misaligned geometry $ALICE_ROOT/MUON/data/transform2.dat.

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.

==========================================================
 How to Merge events
==========================================================

You can merge 2 types of simulated events. For example, 
you can simulate Hijing events, and then simulate muons
merging both.

Merging is done at the sdigits level, so Kinematics files 
of the merged events will just correspond to the 
Config.C simulated file (not to Config_HIJING.C).

You must, first, do the Hijing simulation and store it 
in directory $HIJING_SIM. Note that for merging you 
won't need Kinematics files of the Hijing simulation...

Hijing simulation

aliroot -b << EOF
AliSimulation HijingSim("$HIJING_SIM/Config_HIJING.C")
HijingSim.Run(5)
.q
EOF


Then you can do muon simulation and reconstruction
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
MuonSim.Run(100) // number of muon (Config.C) events
.q
EOF


aliroot -b << EOF
TPluginManager * pluginmanager = gROOT->GetPluginManager()
pluginmanager->AddHandler("AliReconstructor","MUON","AliMUONReconstructor","MUON","AliMUONReconstructor()")
AliReconstruction  MuonRec("galice.root")
MuonRec.SetRunTracking("")
MuonRec.SetRunVertexFinder(kFALSE)
MuonRec.SetRunLocalReconstruction("MUON")
MuonRec.SetFillESD("MUON")
MuonRec.Run()
.q
EOF

==========================================================
 How to play with the CDB
==========================================================

If you'd like to see how the CDB is created, please have a look at the 
MUONCDB.C (work in progress, though).

==========================================================
...on track numbering 
==========================================================

All generated particles, including primary and secondary
particles are put on the stack. The secondary particles are kept
in the stack only if they gave a hit in *any* of the ALICE detectors
The number of all particles placed on the stack for a given event 
can be obtained with
Int_t nPart = AliStack::GetNtrack();
Looping from 0 to nPart via AliStack::Particle(ipart)
gives the particle listing as obtained from the particle generator (primaries) 
and Monte Carlo (secondaries).

The particle response in the detector, a hit, is registered
in the hits tree and the hits are filled with each primary track.
The total number of "tracks" (fills of the tree) can be obtained
with ntracks = AliMUONMCDataInterface::NumberOfTracks(event) and is usually smaller than "nPart".
Since particles can also deposit hits in other detectors than 
the MUON spectrometer, there will be many "tracks" (fills) in the hit-tree
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
    Int_t nhitstot = hitStore->GetSize();
    AliMUONHit* mHit; 
    TIter next(hitStore->CreateIterator());
    while ( ( mHit = static_cast<AliMUONHit*>(next()) ) )
    {   
       Int_t id = mHit->Track(); //gives particle ID on stack
       TParticle* particle = mcDataInterface.Stack(event)->Particle(id);
    }  
}

where mcDataInterface has been obtained by
AliMUONMCDataInterface mcDataInterface("galice.root");

During the procedure to go from hits to digits, the hits 
are summed up such that more than one track can contribute
to a given digit. As a consequence the method
Int_t AliMUONDigit::Track(Int_t trackID)
takes an argument, where "trackID" runs from 0 to 
AliMUONDigit::Ntracks() to provide the reference to *all*
tracks that contributed to it. The returned track ID is the one 
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");

AliMUONVDigitStore* digitStore = di.DigitStore(event);
AliMUONVDigit* mDigit = ... get some digit from the digitStore

for (int tr = 0; tr < mDigit->Ntracks(); tr++)
{
   Int_t hitTrackID = mDigit->Track(tr);
   // get the hits corresponding to this trackID
   AliMUONHitStore* hitStore = mcdi.HitStore(event,hitTrackID);
   // loop over the hits
   TIter hNext(hitStore->CreateIterator());
   AliMUONHit* mHit;
   while ( ( mHit = static_cast<AliMUONHit*>(hNext()) ) )
   {
    Int_t numPart = mHit->Track(); //gives ID of particle on the stack
    Int_t idTrack = mHit->Particle(); //gives flavour code of the particle
   }
}

==========================================================
Macros for MC studies
==========================================================

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. 
This allows to tag if two muons of a given event come from a certain, well-defined 
process, such as J/psi, Upsilons, correlated open charm or open beauty or the 
low masses or if they are of uncorrelated origin. For open beauty/charm it also 
tags the creation process (pair creation, flavour excitation or gluon splitting). 
The classes also allow to tag feed-down or neutral B meson oscillation and 
has a method that checks whether the reconstructed track is a muon or not.

The macros ReadRecoCocktail.C, DecodeRecoCocktail.C and MergeMuonLight.C 
are examples how to use these two classes. DecodeRecoCocktail.C opens the 
generated files, loops over the events and fills an AliMUONTrackLight object 
for every reconstructed track for which the reference to its generated particle 
could be established, using the AliMUONRecoCheck class. 
It then takes the AliMUONTrackLight objects and forms - event by event - 
AliMUONPairLight objects, on a combinatorial basis. For a given event these 
objects are stored in respective TClonesArrays which are then stored in a tree. 
By default, the produced output file is called "MuonLight.root". 
This root file can then be taken by the macro "ReadRecoCocktail.C" that shows, 
on the example of the reconstructed mass and pT of the AliMUONPairLight object,
how to access the available information. For large statistics, in which many 
individual MuonLight.root files are produced, MergeMuonLight.C can be used 
to merge the files and produce one common output root file.

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

===========================================================
 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()

===========================================================
 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.);
    gener->SetPhiRange(0., 360.);
    gener->SetCutOnChild(1);
    gener->SetChildPhiRange(0.,360.);
    gener->SetChildThetaRange(171.0,178.0);
    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

===========================================================
 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.);         
   gener->SetThetaRange(171.000,178.001);
   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()

===========================================================
 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, 
			geoFilenam, filename
                        FirstEvent, LastEvent, 
	                esdFileName,
			ResType, Chi2Cut,
			PtCutMin, PtCutMax,
        		massMin, massMax)

with:
ExtrapToVertex (default -1)
      <0: no extrapolation;
      =0: extrapolation to (0,0,0);
      >0: extrapolation to ESDVertex if available, else to (0,0,0)
geoFilename (default "geometry.root") geometry file name needed to extrap to vertex
filename    (default "galice.root") galice root file name
FirstEvent  (default 0)
LastEvent   (default 10000)
esdFileName (default "AliESDs.root") esd root file name
ResType     (default 553):   553 for Upsilon, anything else for J/Psi
Chi2Cut     (default 100):   keep only tracks with chi2 per d.o.f. < Chi2Cut
PtCutMin    (default 1):     keep only tracks with transverse momentum > PtCutMin
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

===========================================================
 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.
- *fgkTrackAllTracks* : according to the value of this flag, in case that several
  new clusters pass the quality cut, either we consider all the possibilities
  (duplicating tracks) or we attach only the best cluster.
- *fgkRecoverTracks* : if this flag is set to 'true', we try to recover the tracks
  lost during the tracking by removing the worst of the 2 clusters attached in the
  previous station.
- *fgkImproveTracks* : if this flag is set to 'true', we try to improve the quality
  of the tracks at the end of the tracking by removing clusters that do not pass
  new quality cut (within the limit that we must keep at least one cluster per
  the station).
- *fgkSigmaToCutForImprovement* : quality cut used when we try to improve the
  quality of the tracks.

===========================================================
 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
MUONTriggerChamberEfficiency();

//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);

===========================================================
 Still working ..............
===========================================================