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)

• 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

Motivation

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

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()

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

It Starts with the SIDL

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

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.

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

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.

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.

Community Tools

A Java-based GUI for component assembly

Wiki-based documentation of component development

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.

Synergia2 & CQoS

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

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

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.