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)(www.cca-forum.org) And the SciDAC-sponsored Center for Technology for Advanced Scientific Component Software (TASCS)

2. 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 launched in 1998 –SciDAC support beginning in 2001 Motivation

3. Basic CCA Concepts Screenshot of application in the Ccaffeine framework’s GUI 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

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 C C++ f77 f90 Python Java C C++ f77 f90/95 Python 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 4 th 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. Community Tools A Java-based GUI for component assembly Wiki-based documentation of component development

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.