1 / 35

PEP The PHENIX Event Processor

PEP The PHENIX Event Processor. The PHENIX Collaboration presented by S. P. Sorensen University of Tennessee at CHEP97. The PEP Team: Han Geng, Qihang Liu, David P. Morrison , Li Qun, Victor Perevoztchikov , Kyle Pope, Mark Pollark, Soren Sorensen and Yan Zhao. Outline.

cecil
Download Presentation

PEP The PHENIX Event Processor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PEPThe PHENIX Event Processor The PHENIX Collaboration presented by S. P. Sorensen University of Tennessee at CHEP97 The PEP Team: Han Geng, Qihang Liu, David P. Morrison, Li Qun, Victor Perevoztchikov, Kyle Pope, Mark Pollark, Soren Sorensen and Yan Zhao

  2. Outline • PHENIX’s Computing Model • PHENIX Requirements • Types of Analysis Frameworks • Domains and Implementation Choices • Interprocess Communication • User Modules • Data Structure Management • RHIC Off-line Software Collaboration

  3. PHENIX Computing Model

  4. PHENIX’s CPU and Data Storage Requirements CPU Data Production and Storage

  5. PHENIX Analysis Framework Requirement I • Environment • Can operate in a distributed, heterogeneous environment • Can operate in a single node environment • Can operate both on the highest performance chips and the best price/performance chips

  6. PHENIX Analysis Framework Requirement II • Configurability • Can be configured to do all aspects of the PHENIX Data analysis • Will allow the creation of • a small, ``tight'' executable for the single user • a large comprehensive set of executables for the large-scale tasks like Event Reconstruction • Can operate in both batch and interactive mode with same functionality • Will allow already existing software (PISA/PISORP) to be incorporated

  7. PHENIX Analysis Framework Requirement III • Data Access • Will allow the user access to all of PHENIX data through a uniform API • Will allow the user to perform data queries • Will allow full access to both a global, central database and local data bases • Will allow the user to graphical view the data • Will allow access specifically to all data in the online/DAQ system injected into the routing layer

  8. PHENIX Analysis Framework Requirement IV • User Interface • GUI and batch interface shall provide identical functionality • GUI should be tailorable by the user • GUI-batch mode switchable at run time • GUI can run on a small, cheap computers (PC, Mac, etc..) • User Interface the same in all running modes except for a few mode dependent menus. (a la Mac menus)

  9. PHENIX Analysis Framework Requirement V • I/O • Will provide I/O from/to disk, tape, HSMS, memory and the PHENIX routing layer • Visualization • Will provide interface to HEP visualization tools: PAW, ROOT, .. • Will allow all event data and as much static data as possible to be viewed superimposed on the PHENIX geometry

  10. Classical Type ofAnalysis Framework Co-located Module Main Initialization Bookkeeping etc. Event Loop Module Module Control Core vs. User Core vs. User Run time vs. Compile time Run time vs. Compile time Examples GEANT: User PISA: Core ROOT: Core PEP1: Core, Compile PEP2: User, Compile STAF: User, Run ROOT: User, Run PEP: Compile STAF: Compile ROOT: Run

  11. “Modern” Type of Analysis Framework Module Event Loop Main Module Indirection Indirection Module Indirection: Software Bus, Communication Layer • Advantages of indirection: • Insulates Modules (Language …) • Allows distributed architecture • Insulates GUI from Modules

  12. PEP’s LayeredArchitecture (Graphical) User Interface Standard Interface Controller Control Messages Data Opera-tor A Data Opera-tor B Data-base Tool User Layer I/O Tool Event Data Messages Standard Interface Event Data Store Database This is a typical example of an implementation of the “Toaster” Model.

  13. SDC Toaster Model

  14. PEP Domains(Shlaer-Mellor OOA)

  15. PEP Implementation Choices I • GUI: TCL/TK • Allows both GUI and Macro interface • Available on many platforms • Interprocess Communication: PVM • Parallel Virtual Machine • Between TCP/IP and CORBA in complexity, flexibility and overhead • Data Structure Management: DSPACK • Created by Ryszard Zybert et al. for NA49 • Database: ORACLE • Robust and fast for simple data structures • Does the job for off-line • But an OODB might be better in the long run

  16. PEP Functional Units II • Input & Output Tool • Provides all I/O of data structures (as opposed to control data which flows through the GUI) • Data Base Tool • Provides local access to either the central data base or a local, cache data base • Central Data Base Server • Provides access to the central data base at RHIC. Runs on the RHIC cluster. • Visualizer • Provides all graphics services like histogram display, event display and graphical data interaction • Provides monitoring of all PHENIX specific aspects of the data flow

  17. PEP Control and Data Flow

  18. PEP Functional Units I • Controller • The ``brain'' of PEP • Starts and stops all other processes • Controls all communication between processes • Monitors the status of all processes • Allocates resources • Graphical User Interface (GUI) • Provides for all interaction between PEP and the user • Data Operators • Accept data structures as input, perform operations on them and provide data structures as output • Contains 95\% of all user code

  19. PEP Implementation Choices II • Visualization • Spectra: DSPACK & PAW --> DSS • Event display: OnX. • OS: UNIX & NT • UNIX: SGI, HP, DEC, IBM, Sun • NT: On Pentium Pro • Languages: C, C++ • Most of core PEP implemented in C • A bit of FORTRAN for interface to Event Generators and for GEANT

  20. PEP V2 (PEPSI)Single Co-located Configuration

  21. PEP V2Simple Configuration

  22. PEP V2Production System Configuration

  23. PEP Standard Message Passing “Handshake” Procedure

  24. PEP Controller Internal Objects

  25. PEP Controller Main Loop do while ( ActiveOperators ) CheckIn !Checks for mail and !sends it to the postoffice do while ( new mail in PostOffice ) MailMan gets mail with generic address (Dop) MailMan asks Broker for best specific address (Dop.A.1) If ( Specific address exists ) MailMan delivers mail to Proxy Proxy Object sends mail to real object Original mail in Postoffice is destroyed else Original mail is kept end if end do Audit end do

  26. PEP Data OperatorSimple State Model

  27. PEP Data OperatorRealistic State Model

  28. Pep User Module “Hooks”

  29. PEP WAN Access to the Central Database

  30. PEP Physics Module Types

  31. PEP Module Types I(Simulation) • Event Generator [Gen] • Generates simulated events in the form of a list of particles created at the vertex • Hit Generator [Hit] • Accepts the Gen output and generates hits in all sensitive volumes. (GEANT Application) • Signal Generator [Sig] • Accepts the Hit output, sums hits over all readout volumes and calculates the final physics output signal in each read-out channel • FEE Simulator [Fee] • Simulates the response of the front-end electronics to provide the digital signals in each channel. Typical effects: digitization, discriminator walk, pedestals etc.

  32. PEP Module Types II(Trigger) • Level 1 Trigger Simulator [Tl1] • Simulates all aspects of the data handling in the level 1 trigger • Level 2 Trigger Simulator [Tl2] • Simulates all aspects of the data handling in the level 2 trigger • Level 3 Trigger Simulator [Tl3] • Simulates all aspects of the data handling in the level 3 trigger

  33. PEP Module Types III(Initial Off-line) • Calibrator [Cal] • Accepts the raw data as input an either calculates calibrations constants or performs all calibrations and corrections of the raw data. • Local Event Reconstruction [ReA] • Performs all event reconstruction at the detector level which an be done in a stand-alone mode. Examples: Cluster finding in EMC, Hit finding in the Drift Chambers • Sub-system Event Reconstruction [ReB] • Performs all event reconstruction at the sub-system level, which is done based on the input of information from another detector in the same sub-system. Example: Finding muon tracks in the muon tracking systems based on a list of identified muons from the muon identifier.

  34. PEP Module Types IV(Late Off-line) • Global Event Reconstruction [ReC] • Performs all event reconstruction at the global PHENIX level, where information from other sub-systems is necessary. Example: Particle identification • Data Mining [DaM] • Perform all function related to data mining: preparation of data in storage system and search of data. • Analyzer [Ana] • Performs subsequent data analysis.

  35. PEP Current Status • PEP has been frozen as of Mar 1997 • RHIC Software Collaboration • PHENIX has decided to collaborate with STAR and the other RHIC experiments on Core Off-line Software • Straw man model • Analysis Framework: STAF • Display: ROOT • Database: ORACLE • Event Data Storage: Outcome of Computational Grand Challenge Project on Data Organization

More Related