Fun 4 All Structure of Fun 4 All

Fun 4 All

Structure of Fun 4 All Input Managers Fun 4 All. Server DST Raw Data (PRDF) Output Managers DST Analysis Modules PISA Hits Raw Data (PRDF) Simulated PRDF Histogram Manager Root File That’s all there is to it (as long as you don’t look under the hood)

Node Tree • The Node Tree is at the center of the Phenix software universe (but it’s more or less invisible to you). It’s the way we organize our data. • We have 3 different Types of Nodes: • PHComposite. Node: contains other Nodes • PHData. Node: contains any object • PHIOData. Node: contains objects which can be written out • PHComposite. Nodes and PHIOData. Nodes can be written to a file and read back • This file contains root trees, the node structure is reflected by the branch names • We currently save 2 root trees in each output file, one which contains the eventwise information, one which contains the runwise information • Input Managers put Data on the node tree, output managers save selected nodes to a file.

Node Tree for real TOP (PHComposite. Node)/ DCM (PHComposite. Node)/ DST (PHComposite. Node)/ Ph. Had. Cgl. List (PHIOData. Node) Event. Header (PHIOData. Node) Sync (PHIOData. Node) Trig. Lvl 1 (PHIOData. Node) PHGlobal (PHIOData. Node) emc. Cluster. Container (PHIOData. Node) Acc. Cluster (PHIOData. Node) PHCentral. Track (PHIOData. Node) Reaction. Plane. Object (PHIOData. Node) RUN (PHComposite. Node)/ Run. Header (PHIOData. Node) Trig. Run. Lvl 1 (PHIOData. Node) Trig. Run. Lvl 2 (PHIOData. Node) Flags (PHIOData. Node) Detector. Geometry (PHIOData. Node) PAR (PHComposite. Node)/ PRDF (PHData. Node) Fun 4 All prints it out after everything is said and done in the Begin. Run(), this is the tree You see when running our analysis train These Nodes are create by default These Nodes are “special” – they serve as default for the I/O, the objects under the DST Node are reset after every event to prevent mixing of events. You can select objects under the DST Node for saving, objects under the RUN Node are all saved in the output file Fun 4 All can keep multiple node trees and Input/Output Managers can override their default Node where to put the data, but then things get too complicated for this occasion This is only needed for special applications which are not mainstream yet (e. g. embedding).

It’s all about choices - Input • Fun 4 All. Dst. Input. Manager: Reads DST’s, if reading multiple input files it makes sure all data originates from the same event • Fun 4 All. No. Sync. Dst. Input. Manager: Reads DST’s but doesn’t check events for consistency (needed when reading simulated input together with real data for embedding or if you just feel like screwing up) • Fun 4 All. Pisa. Input. Manager: Reads PISA Hits files • Raw Data (PRDF) uses still different mechanism

It’s all about choices - Output • Fun 4 All. Dst. Output. Manager: Write DST’s • Fun 4 All. Event. Output. Manager: Writes Events in prdf format (packet selection possible) • Fun 4 All. Prdf. Output. Manager: Write simulated raw data file.

Your Analysis Module You need to inherit from the Subsys. Reco Baseclass (offline/framework/fun 4 all/Subsys. Reco. h) which gives the methods which are called by Fun 4 All. If you don’t implement all of them it’s perfectly fine (the beauty of base classes) • • • In your class you can implement manyonce additional methods Init(PHComposite. Node *top. Node): ascalled at startup Init. Run(PHComposite. Node *top. Node): called As you like, but these are the ones called by whenever Fun 4 All data from a new run is encountered Process_event (PHComposite. Node *top. Node): called for every event Reset. Event(PHComposite. Node *top. Node): called after each event is processed so you can clean up leftovers of this event in your code End. Run(const int runnumber): called before the Init. Run is called (caveat the Node tree already contains the data from the first event of the new run) End(PHComposite. Node *top. Node): Last call before we quit

Blah – Very nice, but how do I run the show? Fun 4 All provides only building blocks, you need to put them together yourself in your root macro according to your needs void Run. My. Analysis() { g. System->Load("libfun 4 all. so"); g. System->Load(“libmynobelprizewinninganalysis. so"); Fun 4 All. Server *se = Fun 4 All. Server: : instance(); Fun 4 All. Input. Manager *in 1 = new Fun 4 All. Dst. Input. Manager("DSTIN 1"); Fun 4 All. Input. Manager *in 2 = new Fun 4 All. Dst. Input. Manager("DSTIN 2"); se->register. Input. Manager(in 1); se->register. Input. Manager(in 2); in 1 ->Add. File("PWG_Min. Bias_run 4 Au. Au_Central_200 Ge. V_v 01_pro 66 -0000121548 -0003. root"); in 2 ->Add. File("CNT_Min. Bias_run 4 Au. Au_Central_200 Ge. V_v 01_pro 66 -0000121548 -0003. root"); Subsys. Reco *my 1 = new First. Nobel. Prize(); se->register. Subsystem( my 1); Subsys. Reco *my 2 = new Second. Nobel. Prize(); se->register. Subsystem( my 2); se->run(); se->End(); delete se; } Use objects spread over 2 DST’s – you need 2 input managers No path to the input file – our file catalog will find it for you and so protects against us movingcalls filesdetermines or using multiple The order of theyou register. Subsystem() the order Copies reduce the on –our servers In whichtomodules areload called nobody protects you from doing it wrong (user knows best approach)

Master Recalibrator We changed our strategy how to go about reconstructing our data from “start only when all calibrations are final” (which delayed us for a year) to “that’s good enough for tracking, let’s save enough information to run the final calibration later during analysis” (which now delays us for a year) But it’s user friendly – all you need to do is add this to your macro: Fun 4 All. Server *se = Fun 4 All. Server: : instance(); Master. Recalibrator *mr = Master. Recalibrator: : instance(); se->register. Subsystem(mr); BEFORE you register your analysis

Histogram Out. Put Root’s pathetic Tdirectory handling makes it unlikely that you figure out how to create and save histograms on your own reliably (at least that’s my experience). Use the Fun 4 All. Histo. Manager for this #include “Fun 4 All. Histo. Manager. h” My. Analysis: : My. Analysis() { Histo. Manager = new Fun 4 All. Histo. Manager("FUN 4 EXAMPLE Analyzer"); Histo. Manager->set. Outfile. Name( “myhistos. root”); } My. Analysys: : Init(PHComposite. Node *top. Node) { myhist 1 = new TH 1 F(…. ); // myhist 1 should be declared in My. Analysis. h Histo. Manager->register. Histogram(myhist 1); } This will save your histograms when executing the Fun 4 All. Server: : End() in the file “myhistos. root”. If you don’t set the filename it will construct a name from the name of your analysis module

Create your own TTree My biased opinion: creating my own root TTrees is a very painful experience and analyzing them is even worse But aren’t our node trees saved as root trees? Wouldn’t it be nice to just piggy back on its very generic mechanism to do this? It is actually possible – the only thing you need to do is write a class which contains the variables you want to save (on an event by event basis, but you can select which event should be saved). You put this object on the node tree and tell an output manager to write it out. Now you’ve got your own root TTree which you can either analyze it like you analyzed your old tree or you can feed it back into Fun 4 All and use another Subsys. Reco module to analyze it

So you finally admitted to yourself that writing bugfree code is just beyond your current capability Welcome to the club, you are in good company. More than half of last weeks prospective passengers - including me - just joined Here are some short tutorials how to run code checkers: The ever popular and easy to use and understand valgrind (what more than the line number were your code is doing the dirty deed do you want): http: //www. phenix. bnl. gov/WWW/offline/tutorials/valgrind. html Insure is more cryptic but it does find problems valgrind cannot pick up: http: //www. phenix. bnl. gov/WWW/offline/tutorials/insure. html And if your code just bombs out on you, don’t use print statements, use gdb instead which will get you to the problem in no time: http: //www. phenix. bnl. gov/WWW/offline/tutorials/debugging. Tips. html

Fun 4 JDM n. DST Class. A p. DST Class. B p. HST A. Read Two Inputs to have both h+- and pi 0 CNT_Photon PWG_Photon èEvent and Track selection 1 st order èSqueeze the object members on track ( vertex cut , track quality, dead channel mask >Class. B’(common and offline triggerbase ) class(PHENIX+ALICE)+ Framework based on Class. A A. Only good Photons and hadron tracks with event info(vertex, centrality, RP) B. Pi 0 reconstruction and hadron tagging èCorrelation Fnc + Event Mixing

In Details • Common Framework Needed • Fun 4 All based – Fun 4 JDM * framework to run for PHENIX/ALICE – Corrp. DST : module – Corrp. HST : module • Existing classes p. DST : – – Ph. Tree. Header. hh Ph. Cgl. Track. List. hh Ph. Photon. List. hh Ph. Pizero. hh p. DST + p. HST – – – TCard. hh TConst. hh THistos. hh TMix. hh TMonte. Carlo. hh

CVS structure • Discussed • New Scheme of Correlation Analysis: – – Src_alice Src-phenix Src_ndst Src_pdst Name change bit, inside. . – ALICE • Alip. DST • Alip. HST – PHENIX • Php. DST • Php. HST – p. DST – p. HST Green module is framework dependent now( not the base classes) They will be in the main p. DST and p. HST which will be framework Independent !!