There are a few things which are common across several analysis which we would like to share or discuss. ---++++ Selection of Types of Diffractive Events When running on simulated data, one may wish to know whether an event is non-diffractive, single-diffractive, double-diffractive or even possibly centrally-diffractive. In Alice data, the generator used is typically either Phojet or Pythia (6 or 8) for proton-proton collisions. These generators have stored the event type in each event, accessible through the event header. It can be read using the following code: First, we need access to the event generator headers. <pre><verbatim> AliGenPythiaEventHeader* pythiaGenHeader = dynamic_cast<AliGenPythiaEventHeader*>(mcEvent->GenEventHeader()); AliGenDPMjetEventHeader* dpmHeader = dynamic_cast<AliGenDPMjetEventHeader*>(mcEvent->GenEventHeader());</verbatim></pre> Then, depending on which event header object exists (and therefore which generator created the simulated event) we determine the event type using the event type codes individual to the generator. <pre><verbatim> Int_t processType=0; Int_t SD1flag,SD2flag,DDflag,CDflag,ELflag,NDflag; if(pythiaGenHeader) { //pythia6 processType = pythiaGenHeader->ProcessType(); SD1flag = 92; // single diffractive (one side) SD2flag = 93; // single diffractive (other side) DDflag = 94; // double diffractive ELflag = 91; // elastic CDflag = -2; // central diffractive NDflag = -1; // non siffractive Printf("Pythia event %i\n", processType); } else { processType = dpmHeader->ProcessType(); SD1flag = 5; SD2flag = 6; CDflag = 4; DDflag = 7; ELflag = 2; NDflag = 1; Printf("Phojet event %i\n", processType); } </verbatim></pre> From this one can construct a selection for non single diffractive event types. ---++++ Compiling root macros with gcc (without root) A compiled macro runs a lot quicker than one run in interpreted mode in root. One may want to compile the macro so that it runs without root, being a standalone executable which uses root libraries. This requires that the macro includes all the header files from root it will need. Then, one can define a file called "doroot" with the following content: <pre><verbatim>set -x g++ -O2 -pipe -Wall -W -Woverloaded-virtual -fPIC -Iinclude -pthread -I $ROOTSYS/include -o $1.o -c $1.cxx g++ -O2 $1.o -L$ROOTSYS/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathcore -lThread -pthread -lm -ldl -o $1 </verbatim></pre> Make this "doroot" file executable with <verbatim>chmod +x doroot</verbatim> and place it in a directory which is seen by the $PATH variable. Then one can simply compile a root macro with <verbatim> doroot macro </verbatim> as the command automatically looks for the file "macro.cxx" when the argument is "macro". ---++++ Plot two histograms with the ratio underneath It can be useful to have the ratio of two plots directly underneath the histograms with the two plots on the same canvas. This can be done by drawing two TPads in the canvas, with suitable sizing. Below is an example: <pre><verbatim> TCanvas* c1 = new TCanvas("1","Plots1",5,30,900,600); // create new canvas c1->Clear(); TPad*c1npad1 = new TPad("c1npad1","",0,0.2,1,1); // create pad for the plots TPad*c1npad2 = new TPad("c1napd2","",0,0,1,0.2); // create pad for the ratio c1->cd(); // set working area to main area of canvas c1npad1->Draw(); // draw larger pad in main area c1npad1->cd(); // change working area to inside main pad hist1->DrawCopy("p e"); // draw plots to be compared in main pad hist2->DrawCopy("hist same"); c1->cd(); // go back to working area of whole canvas c1npad2->Draw(); // draw smaller pad in main canvas c1napd2->cd(); // set working area to smaller pad histratio->SetStats(0); // setup the options for the ratio plot histratio->SetTitle(); histratio->GetYaxis()->SetTitle("Ratio"); histratio->GetYaxis()->SetTitleSize(0.12); histratio->GetYaxis()->SetTitleOffset(0.3); histratio->GetYaxis()->SetLabelSize(0.1); histratio->GetXaxis()->SetLabelSize(0.1); histratio->GetYaxis()->SetRangeUser(0.8,1.2); histratio->GetYaxis()->SetNdivisions(4,kTRUE); histratio->SetTickLength(0.01,"Y"); histratio->SetMarkerStyle(7); histratio->DrawCopy("p e"); // draw the ratio plot c1->cd(); // go back to main canvas </verbatim></pre> Of course, the names of the histogram will need to be changed to one's own. ---++++ Primary track selection in MC Basically one would like a way to select in the Monte Carlo the final-state long-lived particles coming from the interation vertex and remove any others eg intermediate particles which the generator kept track of (q,g), weak decay daughters, products of secondary interactions. There are (at least) two ways to do this using only methods from AliRoot. Both methods require that your analysis task obtains a pointer both the the AliMCEvent and AliStack objects. Eg <pre><verbatim> AliMCEvent* mcEvent = MCEvent(); AliStack* stack = mcEvent->Stack();</verbatim> </pre> One should then begin a loop over the MC tracks <pre><verbatim>Int_t nPrim = stack->GetNprimary(); for (Int_t iMc = 0; iMc < nPrim; ++iMc) {</verbatim></pre><verbatim>... </verbatim><pre><verbatim> } </verbatim> </pre> Inside this loop you have the choice of doing _one_ of the following <literal><pre class='TMLverbatim'>if (stack->IsPhysicalPrimary(iMc)){ TParticle* particle = stack->Particle(iMc); TParticlePDG* partPDG = particle->GetPDG(); if (partPDG->Charge()!=0) { fHistEtaMC->Fill(particle->Eta()); } } </pre></literal> or <literal><pre class='TMLverbatim'>if (AliPWG0Helper::IsPrimaryCharged(particle,nPrim,kFALSE)) { fHistEtaMC->Fill(particle->Eta()); }</pre></literal> The above examples are not complete, they just fill a simple η histogram (if you try both together remember to change the name of the second histogram). All of the methods used have online documentation. [[http://aliceinfo.cern.ch/static/aliroot-new/PWG0/AliPWG0Helper.cxx][AliPWG0Helper::IsPrimaryCharged()]] [[http://aliceinfo.cern.ch/static/aliroot-new/html/roothtml/AliStack.html#AliStack:IsPhysicalPrimary][AliStack::IsPhysicalPrimary() ]] Pros and cons. The AliPWG0Helper method needs fewer lines of user code but requires the PWG0base par file in order to run on CAF. The AliStack method needs more user coding, including retrieval of TParticle and TParticlePDG objects, but works from the standard par file AF-v4-16. I have checked that the methods select the same number of tracks for 200000 events from LHC09a4 production on CAF (over 10^7 particles). -- Main.LeeBarnby - 16 Mar 2009</verbatim></pre>
This topic: ALICE
>
WebHome
>
AliceCommonAnalysis
Topic revision: r5 - 06 Jun 2011 - _47C_61UK_47O_61eScience_47OU_61Birmingham_47L_61ParticlePhysics_47CN_61arvinder_32palaha
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback