Motivation for TOPS

1
Motivation for TOPS
Project Overview
TOPS is developing a toolkit of open source
solvers for PDEs that arise in many DOE mission
areas. These algorithms primarily multilevel
methods aim to reduce solver bottlenecks by
magnitudes at the terascale, with goals of
usability, robustness, algorithmic efficiency,
and the highest performance consistent with
these.
Salient application properties

• Not just algorithms, but vertically integrated
  software suites
• Portable, scalable, extensible, tunable
  implementations
• Motivated by representative apps, intended for
  many others
• Starring Hypre, PETSc, Sundials, SuperLU, and
  TAO, among other existing packages
• Driven by three applications SciDAC groups
• LBNL-led 21st Century Accelerator designs
• ORNL-led core collapse supernovae simulations
• PPPL-led magnetic fusion energy simulations
• Coordinated with other ISIC SciDAC groups

• Multirate
• requiring fully or semi-implicit in time solvers
• Multiscale
• requiring finest mesh spacing much smaller than
  domain diameter
• Multicomponent
• requiring physics-informed preconditioners,
  transfer operators, and smoothers

Scope for TOPS
TOPS philosophy

• Solution of a system of PDEs is rarely a goal in
  itself
• Actual goal is characterization of a response
  surface or a design or control strategy
• Solving the PDE is just a forward map
• Together with analysis, sensitivities and
  stability are often desired
• Software tools for PDE solution should also
  support related follow-on desires
• Demand for resolution is virtually insatiable
• Relieving resolution requirements with modeling
  (e.g., turbulence closures, homogenization) only
  defers the demand for resolution to the next
  level
• Validating such models requires high resolution
• Processor scalability and algorithmic scalability
  (optimality) are critical

• Solvers are employed in many ways over the life
  cycle of an applications code
• During development and upgrading, robustness (of
  the solver) and verbose diagnostics are important
• During production, solvers are streamlined for
  performance
• Tunability is important
• Solvers are used by people of varying numerical
  backgrounds
• Some expect MATLAB-like defaults
• Others want to control everything, e.g., even
  varying the type of smoother and number of
  smoothings on different levels of a multigrid
  algorithm
• Multilayered software design is important

• Design and implementation of solvers
• Time integrators, with sens. analysis
• Nonlinear solvers, with sens. analysis
• Optimizers
• Linear solvers
• Eigensolvers
• Software integration
• Performance optimization

Why is TOPS needed?

• What exists already?
• Adaptive time integrators for stiff systems
  variable-step BDF methods
• Nonlinear implicit solvers Newton-like methods,
  FAS multilevel methods
• Optimizers (with constraints) quasi-Newton RSQP
  methods
• Linear solvers subspace projection methods
  (multigrid, Schwarz, classical smoothers), Krylov
  methods (CG, GMRES), sparse direct methods
• Eigensolvers matrix reduction techniques
  followed by tridiagonal eigensolvers, Arnoldi
  solvers

• What is wrong?
• Todays components do not talk to each other
  very well
• Mixing and matching procedures too often requires
  mapping data between different storage structures
  (taxes memory and memory bandwidth)
• Logically innermost (solver) kernels are often
  the most computationally complex should be
  designed from the inside out by experts and
  present the right handles to users
• Many widely used libraries are behind the times
  algorithmically

T3D

• A continuous operator may appear in a discrete
  code in many different instances
• Optimal algorithms tend to be hierarchical and
  nested iterative
• Processor-scalable algorithms tend to be
  domain-decomposed and concurrent iterative
• Majority of progress towards desired highly
  resolved, high fidelity result occurs through
  cost-effective low resolution, low fidelity
  parallel efficient stages
• Operator abstractions and recurrence are
  important
• No general purpose PDE solver can anticipate all
  needs
• Why we have national laboratories, not numerical
  libraries for PDEs today
• A PDE solver improves with user interaction
• Pace of algorithmic development is very rapid
• Extensibility is important

SP4

• Hardware changes many times over the life cycle
  of a solver package
• Processors, memory, and networks evolve annually
• Machines are replaced every 3-5 years at major
  DOE centers
• Codes persist for decades
• Portability is critical
• Solvers are employed as part of a larger code
• Solver library is not only library to be linked
• Solvers may be called in multiple, nested places
• Solvers typically make callbacks
• Solvers should be swappable
• Solver threads must be isolable from other
  component threads, including other simultaneous
  instances of themselves

Expectations TOPS has of users

• Willingness to experiment with novel algorithmic
  choices optimality is rarely achieved beyond
  model problems without interplay between physics
  and algorithmics!
• Adoption of flexible, extensible programming
  styles in which algorithmic and data structures
  are not hardwired
• Willingness to make concrete requests, to
  understand that requests must be prioritized, and
  to work with us in addressing the high priority
  requests

for more information ...
http//www.tops-scidac.org