1 / 17

Components for Beam Dynamics

Components for Beam Dynamics. Douglas R. Dechow, Tech-X Lois Curfman McInnes, ANL Boyana Norris, ANL With thanks to the Common Component Architecture (CCA) Forum (www.cca-forum.org) And the SciDAC-sponsored Center for Technology for Advanced Scientific Component Software (TASCS).

susanne
Download Presentation

Components for Beam Dynamics

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. Components for Beam Dynamics Douglas R. Dechow, Tech-X Lois Curfman McInnes, ANL Boyana Norris, ANL With thanks to the Common Component Architecture (CCA) Forum (www.cca-forum.org) And the SciDAC-sponsored Center for Technology for Advanced Scientific Component Software (TASCS)

  2. Motivation • Complexity of scientific software increases with simulation fidelity, multi-physics coupling, computer power software crisis • Component technology is well established outside of high-performance computing (HPC) as a way to manage software complexity • Much enterprise software is component software, but commercial implementations do not support HPC • The Common Component Architecture (CCA) brings component software approach to scientific HPC • Grass-roots effort launchedin 1998 • SciDAC supportbeginning in 2001

  3. Basic CCA Concepts • Frameworks • Hold components while applications are assembled and executed • Control the connections of ports • Provide standard services to components • Components • Are units of software development/functionality • Interact only through well-defined interfaces • Can be composed into applications based on their interfaces • Ports • Are the interfaces through which components interact • Follow a provides/uses pattern • Provided ports are implemented by a component • Used ports are functionality a component needs to call Screenshot of application in the Ccaffeine framework’s GUI

  4. Provides-Uses Pattern • FooComponent: • Declares that it will support a particular port by calling addProvidesPort() • BarComponent: • Declares that it requires a set of services by calling registerUsesPort() • Retrieves reference to port by calling getPort()

  5. Language Interoperability • Scientific software is increasingly diverse in use of programming languages • In a component environment, users should not care what language a component is implemented in • Typical “point-to-point” solutions to language interoperability are not suitable for a component environment • The Babel language interoperability tool provides a common solution for all supported languages • Currently: Fortran, Python, C, C++, Java • Extensible to other languages • Scientific Interface Definition Language (SIDL) provides language-neutral way of expressing interfaces f77 f77 C f90/95 C f90 Python C++ C++ Python Java Java

  6. It Starts with the SIDL

  7. Benefits to Software Developers • Components are natural units of decomposition and interaction for both software and developers • Manage software complexity • They enable scientists to work together as a cohesive scientific enterprise, across disciplines, geographical boundaries, and technical preferences by facilitating… • Collaboration around software development • Interoperability and reuse of software tools • Community standards for scientific software • Coupling of disparate codes CCA-based simulation of OH concentration in advective-diffusive-reactive simulation using 4th order Runge-Kutta-Chebyshev integrator on 4 levels of adaptively refined mesh Courtesy of J. Ray, Sandia National Laboratories

  8. Accelerator Modeling and Software Components • Computational accelerator community • Tremendous investment in software applications. • Codes written in a variety of languages. • Target a range of computational platforms. • The CCA Approach • Enables the community to leverage existing applications, creating modular, reusable software components that encapsulate useful functionality, facilitating coupling of historically independent codes to add new capabilities.

  9. Accelerator Simulation using CCA Components (CCA/Synergia) • Using CCA tools and specifications, prototype an accelerator simulation from reusable components. • Develop components based on the following accelerator codes and • Synergia2 (FNAL), • MaryLie/Impact (LBL/U. Maryland), and • High-performance numerical toolkit, PETSc (ANL) • Participants: • Tech-X Corporation • FNAL • ANL

  10. CCA/Synergia Goals • Foster a component community in computational accelerator physics • Demonstrate a accelerator simulation by creating components from beam dynamics codes that were not designed to work together. • Create a component assembly GUI for accelerator simulation development • Once a large enough pool of accelerator components exists, create models visually. • Develop component creation tutorials for the beam dynamics community.

  11. Beam Dynamics Components • Accelerator modelling components: • F90-based beam optics components (quadrupoles and drifts) from the MaryLie/Impact application. • C++ and F90 particle store components from the Synergia2 framework (FNAL). • A newly implemented C++-based space charge solver that makes use of Synergia2, PETSc (ANL), and FFTW. • Component interfaces allowed us to capture and make available only the functionality that was desired from the existing codes.

  12. Wiki-based documentation of component development Community Tools A Java-based GUI for component assembly

  13. Computational Quality of Service (CQoS) • Common component interfaces provide easy access to suites of independently developed algorithms and implementations. No single approach can perform best for all circumstances. • Challenge: How, during runtime, can we make make sound choices for reliability, accuracy, and performance, taking into account the problem instance and computational environment? • Composition: select initial component implementations and configuration parameters • Reconfiguration: change parameters • Substitution: change implementations • CQoS: Research initiative in the TASCS SciDAC center • Developing tools to help with automatic selection and configuration of components to suit a particular computational purpose and environment.

  14. Synergia2 & CQoS

  15. Next Six Months • Continue to develop Synergia components for particle tracking, optics, and solvers in the area of space charge effects. • Develop alternative solver component implementations (with TOPS) • Evaluate original Synergia code and componentized version on ILC models

  16. CQoS Enabling Work Items • Complete Initial Synergia componentization (begin work to support additional coherent effects: electron cloud) • Develop alternative solver component implementations (with TOPS) • Populate performance database with model results • Analyze performance data for initial parameter selection • Implement beam dynamics components for dynamic parameter configuration and component replacement

  17. CCA/Synergia Results/Future • CCA tools are flexible enough that non-CCA Synergia2 and MaryLie/Impact simulations can still be used as-is. • Interface-based development practices have allowed us to experiment with component granularity--started with large, coarse components • Prototype demonstrates method for moving to large, integrated physics modeling necessary for ILC.

More Related