# JET ELECTRON ANALYSIS MACROS AND GOODIES

Please, also see our TWiki Page.

This example performs a JETAN FastJet analysis and an electron analysis.

Copy the PWG4/macros/electrons subdirectory to your local work directory.  Replace "kread" with your username in all of the files.  Be sure to replace the email address with yours in mergeout.jdl and mergeoutscaled.jdl.

To execute this example create a subdirectory in AliEn called $HOME/work12. Then, from your local work directory, type: • parmaker all remote • root -q -b -l mylauncher.C That will do a robust file upload and submit the job. If you need to submit the job again, just do this: • aliensh • cd ~/work12 • submit anaJete.jdl Later, merge the output histograms via: • submit mergeout.jdl • submit mergeoutscaled.jdl The example is set for input (production) ESDs. To adjust for an input AOD in AliEn:: • Create a new file mycollect.xml for input AODs using the find command in AliEn (see below). • Change "ESD" to "AOD" in the splitarguments line of anaJete.jdl. To run locally, just type • anaJete.sh To adjust for a local input AOD: • Adjust INDIR and PATTERN in anaJete.sh to point to an AOD directory. • Change anaInputData to "AOD" in anaJete.sh. The previous step automatically does all of this: • Change kInputData to "AOD" in anaJete.C • Change kInputIsESD to kFALSE in ConfigJetAnalysisFastJet.C. • Change kInputIsESD to kFALSE in ConfigAnalysisElectron.C. • Change kFollowsFilter to kFALSE in ConfigJetAnalysisFastJet.C. • Change kFollowsFilter to kFALSE in ConfigAnalysisElectron.C. In order to merge two input AODs, follow the steps above for an input AOD and • Change kMergeAODs to kTRUE in anaJete.C. #### PARMAKER PAR files can be made as usual by typing: • cd$ALICE_ROOT
• make JETAN.par

Note that that requires write access to $ALICE_ROOT. Also, it is not yet possible to properly include all of the contents of FASTJETAN.par using the make command. The parmaker goody can build good PAR files immediately after the svn checkout of AliRoot without requiring write-access to$ALICE_ROOT.  It does not depend on doing $ALICE_ROOT/make. It knows how to prepare a functional FASTJETAN.par. To make new PAR files directly from your work directory type: • parmaker all remote OR • parmaker ANALYSIS remote • parmaker ANALYSISalice remote • parmaker AOD remote • parmaker EMCALUtils remote • parmaker ESD remote • parmaker FASTJETAN remote • parmaker JETAN remote • parmaker PHOSUtils remote • parmaker PWG4PartCorrBase remote • parmaker PWG4PartCorrDep remote • parmaker STEERBase remote #### MYLAUNCHER The mylauncher.C goody uses plugin technology to achieve robust file upload and AliEn job submit. Just edit the first few lines of mylauncher.C according to the instructions in the comments near the top of the file. Then, type • root -q -b -l mylauncher.C #### FIND To construct your own xml file, type for example: • aliensh • find -x mycollect /alice/sim/PDC_08b/LHC08d10/50036/0* AliESDs.root > mycollect.xml #### FASTJET IN ALIEN Even though cgal and boost are invoked by the JDL, they do not actually appear in the JDL. The PackMan AliEn package facility will indeed properly load the external fastjet package and its dependencies using the JDL in this example. #### FASTJET LOCAL INSTALLATION Assume the local top installation directory name is /work2. Then, #### INSTALL BOOST • cd /work2/boost • download boost_1_39_0.tar.gz from http://www.boost.org/ • gunzip boost_1_39_0.tar.gz • tar -xvf boost_1_39_0.tar #### INSTALL CGAL However, one may use the existing /usr/include/boost library headers in fact. There is a CGAL build command to specify the boost location. • cd /work2/cgal • download CGAL-3.3.1.tar.gz from http://www.cgal.org/ • gunzip CGAL-3.3.1.tar.gz • tar xvf CGAL-3.3.1.tar • cd CGAL-3.1.1 • ./install_cgal -i • t • b • i • setenv CGAL_MAKEFILE "/work2/cgal/CGAL-3.3.1/make/makefile_i686_Linux-2.6_g++-3.4.6" #### INSTALL FASTJET As explained in$ALICE_ROOT/JETAN/README_FASTJET, sed the .hh files:

• cd /work2/fastjet/fastjet-install/include
• sed -i -e 's/^FASTJET_BEGIN_NAMESPACE/namespace fastjet \{/' \
-e 's/^FASTJET_END_NAMESPACE.*/\} \/\/ fastjet namespace /' \
-e 's/^#define FASTJET/\/\/ #define FASTJET/' \
fastjet/*.hh fastjet/*/*.hh

• setenv CGAL_MAKEFILE "/work2/cgal/CGAL-3.3.1/make/makefile_i686_Linux-2.6_g++-3.4.6"
• setenv CGAL_LIB "/work2/cgal/CGAL-3.3.1/lib/i686_Linux-2.6_g++-3.4.6"
• setenv LD_LIBRARY_PATH $CGAL_LIB\:$LD_LIBRARY_PATH
• setenv FASTJET "/work2/fastjet/fastjet-install"
• setenv LD_LIBRARY_PATH $FASTJET/lib\:$LD_LIBRARY_PATH

#### MERGING HISTOGRAMS WHEN USING PRODUCTIONS WITH MULTIPLE PYTHIA PT HARD BINS

ALICE official PYTHIA simulations are often produced and stored according to multiple PYTHIA pT hard bins ("bins").   In order to assemble the user's analysis histograms from various bins and subjobs to produce an overall total yield, several points should be noted.  Individual subjobs should not analyze data from multiple bins.   Resubmitting jobs should not result in double-counting histograms from the same individual AOD or ESD root files.   A completely correct assembling can not be achieved without storing and carrying along the total number of PYTHIA trials, merging histograms with continued accumulation of the number of total trials for that bin, and final division by the total number of PYTHIA trials of the histograms for that given bin, before merging results for multiple bins.   Such a technique has been completly developed for the electron analyses and will be implemented soon for the PWG4 electron analyses and is already used by the PWG4 Jet Task analyses.   In the mean time, in the limit of equal number of PYTHIA trials per subjob (which is only approximate and violated for subjobs with different number of events in a given subjob for the same bin), an effective approximate techniqe is available using all of the existing code and macros.   This approximation simply requires that the user merge the histograms for a given bin, then scale those resultant histograms by one over the number of subjobs for that bin, repeat this for every bin, and then merge the scaled resultant histograms from all the bins.   Note that this has the following benefits: It removes the arbitrariness of the number of successful subjobs per bin.  It reduces the number of histograms to ever be merged at one time. It is very beneficial (if possible) to have at least one successful subjob for every pT hard bin.   The approximate technique proceeds as follows:

• Adjust the value of worksubdir and maxbin in mymerger.C.
• Replace the existing username with yours in mergeoutscaledi.jdl.
• root -b -x mymerger.C
• aliensh
• cd /output/merged     (after all of the histosscaled-mergednn.root have been produced)
• cp histoss* file:
• (Consider making a backup of these files locally since they will be overwritten.  They can simply be redownloaded from AliEn.)
• Adjust binlinst in MergeFilesInBins.C to indicate which local histosscaled-mergednn.root files are non-empty.
• root -b -x MergeFilesInBins.C
• The produced TOTALhistosscaled.root is appropriate to use (after renaming) as input to plotMCRates.C.

This will later be replaced by a one-step merge macro after the electron analyses adopt the above-mentioned treatment based on nTrials throughout the manipulations.

#### REAL DATA PRODUCTION

Official reconstruction of raw data to make official ESDs is automatically triggered by the following events:

• Raw data completely transferred to CASTOR.
• Shuttle is done.
• "Good run" flag set in the ALICE logbook.
• Less than 2000 jobs waiting in AliEn queue for Raw production user.

When those conditions are satisfied, a job is automatically submitted to reconstruct the raw data in AliEn on the GRID.  The following scripts for that reconstruction are archived in AliEn:  /alice/cern.ch/user/a/alidaq//rec.C, rec.jdl, tag.C, validation.sh and /alice/cern.ch/user/a/alidaq/bin/LHC09c.sh where the current "LHC period" is LHC09d.   The file rec.jdl presently specifies the analysis tag AliRoot v4-17-Rev-20.   (Additionally, raw data can be submitted manually for official reconstruction on CAF.)

The present AliRoot analysis tags suffer from an EMCAL geometry problem.  The fix is available in trunk but will not be ported to a tagged release until about 9 December 2009. So, all official production ESDs for real data produced prior to that date will not have EMCal clusters matched to tracks.  The next analysis tag is expected to have the necessary geometry fix to properly reconstruct raw EMCAL data and have satisfactory matches.   Most users (except experts involved in details such as track matching) will be able to simply wait about half a day for ESDs to be automatically produced and will not need to reconstruct raw data themselves.

Real data "chunks" are located in AliEn as follows (for Run 104321 for example)

/alice/data/2009/LHC09d/000104321/raw/09000104321018.50.root

EMCAL standalone raw data is located in AliEn at locations such as:

/alice/data/2009/LHC09d_EMCAL

#### REAL DATA ANALYSIS

Official ESDs (presently with an EMCAL geometry bug to be corrected for ESDs produced after 9 December 2009) are located in AliEN at locations such as:

/alice/data/2009/LHC09d/000104321/ESDs/pass1/09000104321018.50/AliESDs.root .

Given the present small quantities of data, "grid interactive mode" (mode 3) is very convenient and avoids any need to copy the data locally.  First, as usual, one must prepare a collection (as above) via (for instance):

• find -x mycollect /alice/data/2009/LHC09d/000104321/ESDs/pass1 AliESDs.root > mycollect.xml
• Just use a recent version of trunk and type "parmaker all remote" with no need for OCDB, etc.
• Adjust anakMC to 0 in anaJete.sh (this will automatically adjust other some flags and calls in anaJete.C and ConfigAnalysisElectron.C)
• Adjust MODE to 3 in anaJete.sh.
• For the time being