1 / 19

Architecture of Collaborating Frameworks

Architecture of Collaborating Frameworks. Andreas Pfeiffer CERN IT/API andreas.pfeiffer@cern.ch B.Ferrero Merlino, R.Giannitrapani, F.Longo, R.Nartallo, P.Nieminen, AP, M.G.Pia, G.Santin Round Table on 21st Century Monte Carlo Methods for Space Applications June 13-15, ESTEC, Noordwijk NL.

althea
Télécharger la présentation

Architecture of Collaborating Frameworks

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. Architecture of Collaborating Frameworks Andreas Pfeiffer CERN IT/API andreas.pfeiffer@cern.ch B.Ferrero Merlino, R.Giannitrapani, F.Longo, R.Nartallo, P.Nieminen, AP, M.G.Pia, G.Santin Round Table on 21st Century Monte Carlo Methods for Space Applications June 13-15, ESTEC, Noordwijk NL Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  2. Outline • Motivation • Collaborating Frameworks • Geant-4: Simulation, Visualisation, User Interface and Analysis • Summary Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  3. Introduction and Motivation • Huge increase in complexity of modern s/w • Needs design on a larger scale • overall system structure: architecture • beyond data structures and algorithms • Example: Detector Simulation • defining geometry and materials • defining physics processes • interactive work • visualisation • data analysis Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  4. Design Levels: an analogy Image the project is not to build software but to go on an inter-planetary journey... Architectural design Mechanistic design Detailed design decide which planet to fly to The Greasy Spoon select the flight path choose where to have lunch Bill Watterson taken from Bob Jones (ATLAS)

  5. Scale and processes:Building a dog house • Can be built by one person • Minimal modelling • Simple process • Simple tools Rational Software Corporation taken from Bob Jones (ATLAS)

  6. Scale and processes:Building a family house • Built by a team • Modelling • Simple plans, evolving to blueprints • Well-defined process • Architect • Planning permission • Time-tabling and Scheduling • ... • Power tools Rational Software Corporation taken from Bob Jones (ATLAS)

  7. Scale and processes:Building a skyscraper • Built by many companies • Modelling • simple plans, evolving to blueprints • scale models • engineering plans • Well-defined process • architectural team • political planning • infrastructure planning • time-tabling and scheduling • selling space • Heavy equipment Rational Software Corporation taken from Bob Jones (ATLAS)

  8. Components and Frameworks • Component • a correlated group of classes together with their interactions • typically determined during domain composition of OO analysis phase • only very weak dependence on (classes of) other components through use of Abstract Interfaces • Framework • reusable design of (part of) a software system • described by sets of abstract classes and the way instances of these collaborate Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  9. Abstract Interfaces • Abstract Interfaces • only pure virtual methods, inheritance only from other A.I. • components use other components onlythrough their A.I. • defines a kind of a “protocol” for a component • Maximize flexibility and re-use of packages • allow each component to develop independently • re-use of existing packages to implement components reduces start-up time significantly • De-couple implementation of a package from its use Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  10. Collaborating Frameworks • Allow re-use (if properly designed) • existing libs can be wrapped easily • Maximize flexibility through use of Abstract Interfaces • implementation can be changed • Rapid development cycle • no need to implement full Interface from beginning • implementation can concentrate on important items • Reduces maintenance overhead • implementations evolve independently Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  11. Geant-4 Toolkit • Description of detector geometry and material • including CAD interface (STEP) • Simulation of physics processes • flexible yet accurate simulations needed • User Interface • to control flow of execution • Visualisation • detector geometry, particle tracks • Analysis • histogramming of physics quantities Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  12. Geant-4 Simulation (I) • Simulation of physics processes • Electromagnetic processes • Standard processes, Low energy extensions, Muon processes, Optical photons • Hadronic processes • Data driven – neutron transport & isotope production • Theory driven modelling • Transportation in fields • Parametrization for fast simulation • User can extend any of the processes • through use of abstract interfaces • adapt for special needs Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  13. Geant-4 Simulation (II) • Control through “steps” through setup • Run, Event, Track, Step • Select and apply appropriate physics process • at each step • Update list of particles to transport • interactions, decays, ... • Possibly interact with user (via call-backs) • show selected events (EventDisplay) • create/update statistical information (Histograms, ...) • decide to continue/skip/abort event Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  14. Geant-4 User Interface • Designed for various categories of users • G-4 developer, application developer, end user • Two phases of user user actions • setup of simulation • control of event generation and processing • User Interface category separated from actual command interpreter (intercoms) • using abstract G4UIsession class • Several implementations exist • command-line (batch and terminal) • GUIs (X11/Motif, Windows, OPACS, Java) Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  15. Geant-4 Visualization • Control of several kinds of visualisation • Detector geometry • particle trajectories • hits in the detectors • Using abstract G4VisManager class • takes 3-D data from geometry/track/hits • passes on to abstract visualization driver • G4VGraphicsSystem (initialization) • G4VSceneHandler (processing 3-D data for vis.) • G4VViewer (rendering the processed 3-D data) Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  16. Geant-4 Analysis • Using abstract G4VAnalysisManager class • uses abstract G4VAnalysisSystem class for initialization • but “hides” instance from user using Proxy-pattern • basically forwarding all method calls to analysisSystem • User defined instance of AnalysisManager • create histograms (through HistogramFactory) • simple plots • storing of histograms • More complex analysis (e.g., fit) done in Analysis System started externally Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  17. G4Analysis category Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  18. GammaRayTelescope • In parallel to event display • Online histogramming required • fast feedback • independent from Analysis Tool Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

  19. Summary • Abstract Interfaces de-couple components of frameworks • Weakly coupled components and frameworks have large advantages • ease of re-use of a component • flexibility through independence of implementation • maintainability through independent evolution of components • Example using Geant-4 and AIDA compliant analysis tools: XRayTelescope Andreas Pfeiffer, CERN/IT-API, andreas.pfeiffer@cern.ch

More Related