# Presentation: 342959

## Motivation for TOPS

- a U.S. DOE
- SciDAC Project

** ****For more information ...**

**http://www.math.odu.edu/~keyes/scidac**

**Motivation for TOPS**

**Not just algorithms, but vertically integrated software suites**
**Portable, scalable, extensible, tunable implementations**
**Motivated by representative apps, intended for many others**
**Starring ****hypre**** and ****PETSc****, 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**

**Many DOE mission-critical systems are modeled by PDEs**
**Finite-dimensional models of PDEs must be large for accuracy**
**Qualitative insight is not enough (Hamming notwithstanding)**
**Simulations must resolve policy controversies**
**Algorithms are as important as hardware in supporting simulation**
**Easily demonstrated for PDEs in the period 1945–2000 **
**Continuous problems provide exploitable hierarchy of approximation models, creating hope for “optimal” algorithms**
**Software lags both hardware and algorithms**

**Salient Application Properties**

**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**

**Not linear**
**Not selfadjoint**
**Not structured**

**Convergence rate nearly independent of discretization parameters**
**Multilevel schemes for linear and nonlinear problems**
**Newton-like schemes for quadratic convergence of nonlinear problems**
**Convergence rate as independent as possible of physical parameters**
**Continuation schemes**
**Asymptotics-induced, operator-split preconditioning**

**Keyword, Key Challenge: “Optimal”**

***The solver is a key part, but  not the only part, of the simulation that needs to be scalable***

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

**Scope for TOPS**

**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**

**Expectations TOPS has of Users**

**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?**
**Today’s 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**

**Solution of a system of PDEs is rarely a goal in itself **
**PDEs are solved to derive various outputs from specified inputs**
**Actual goal is characterization of a response surface or a design or control strategy**
**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 **

**TOPS Philosophy**

**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**

**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**

**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**