pressio C++ library#

Documentation of the C++ library, one element of the Pressio ecosystem.

This work was started with a focus on projection-based reduced-order models (ROMs), which is a strongly multidisciplinary topic. Working towards a production-level ROM capability inevitably means spanning multiple fields ranging from, e.g., linear algebra, nonlinear solvers and optimization, to time integration, distributed computing and HPC. This constitutes a substantial challenge to tackle, whose complexity increases if aiming to develop a generic library.

To start such a project from the ground up, grow it and then being able to maintain it, we believe modularity, abstractions and well-defined APIs to be fundamental design principles to rely on. This has been, and still is, at the core of our development effort, and has lead to a highly modular design of pressio (see table below): each component (level) of the stack covers a specific capability and depends, via well-defined public APIs, on the ones below it. This has required (and still does) a considerable development effort, since each component needs “attention” and can easily be scoped into an independent, full-time project.

So why doing all this rather than adopting a different, simpler approach, for example, limiting and hiding as implementation some of the supporting functionalities? Because we believe the current structure/design offers several major benefits that would be hard—and in some cases impossible—to obtain otherwise: flexibility, extensibility, maintainability, and usability of each component on its own. One drawback is that at any point in time, the various components might have different maturity levels, so reaching a comparable and solid maturity across the stack might take some time—our current goal is to obtain in version 1.0.0 a uniform maturity level at least across the rom, ode and solvers components. Please keep this in mind while browsing the documentation and the code.


Description

Header(s)

rom

concepts
(linear) subspaces
Galerkin: steady
Galerkin: unsteady
LSPG: steady
LSPG: unsteady

<pressio/rom_concepts.hpp>
<pressio/rom_subspaces.hpp>
<pressio/rom_galerkin_steady.hpp>
<pressio/rom_galerkin_unsteady.hpp>
<pressio/rom_lspg_steady.hpp>
<pressio/rom_lspg_unsteady.hpp>
<pressio/rom.hpp> includes all

ode

concepts
explicit steppers
implicit steppers
advance_<*> fncs

<pressio/ode_concepts.hpp>
<pressio/ode_steppers_explicit.hpp>
<pressio/ode_steppers_implicit.hpp>
<pressio/ode_advancers.hpp>
<pressio/ode.hpp> includes all

solvers_nonlinear

concepts
Newton method
Gauss-Newton
Lev.-Marq.

<pressio/solvers_nonlinear_concepts.hpp>
<pressio/solvers_nonlinear_newton.hpp>
<pressio/solvers_nonlinear_gaussnewton.hpp>
<pressio/solvers_nonlinear_levmarq.hpp>
<pressio/solvers_nonlinear.hpp> includes all

solvers_linear

linear dense (on-node) solvers

<pressio/solvers_linear.hpp>

qr

QR factorization functionalities

<pressio/qr.hpp>

ops

shared-memory/distributed linear algebra kernels specializations

<pressio/ops.hpp>

expressions

expressions templates, e.g.: span, diagonal, subspan

<pressio/expressions.hpp>

type_traits

type traits and detection

<pressio/type_traits.hpp>

utils

logger, constants, etc

<pressio/utils.hpp>

mpl

metaprogramming functionalities

<pressio/mpl.hpp>

Get Started#

Generic programming and concepts#

Arguably the main foundation of pressio is the use of generic programming–or, more humbly, we can at least say that it is what we strive for. Since the early development stages, we have relied on concept-driven design. Note, that, if you have used or use C++ templates, you have used concepts knowingly or not. This is because when you write a function or class template, you have some expectations of what a template needs to expose/do. C++20 concepts are, in some sense, a way to explicitly formalize those expectations.

Until we can stably upgrade to C++20, we cannot by default use C++20 concepts, so we currently guard the concepts in pressio inside a preprocessor directive #ifdef PRESSIO_ENABLE_CXX20. This can be enabled by using a C++20 compliant compiler and setting -DCMAKE_CXX_STANDARD=20 at configure time. The behavior is as follows:

  • if PRESSIO_ENABLE_CXX20 is enabled: concepts are compiled and enforced stricto sensu on the pressio APIs as discussed by this documentation

  • if PRESSIO_ENABLE_CXX20 is disabled: this is the default case because the default pressio C++ standard is currently C++14. In this case, the “C++20 concepts” are not compiled but the constraints they represent are still valid and implemented differently such that their enforcement is done via a combination of SFINAE and static asserts.

Important

Well-defined concepts are hard to design and it takes time. Concepts used in pressio are still being developed. Some are more mature than others. The approach we adopt is to first focus on the syntax, then then we will revise them with proper semantics. Keep this in mind if some concepts seem incomplete.

License and Citation#

The full license (BSD-3) is available here.

Sooner or later we will publish this… in the meantime, you can find on arXiv an (outdated) preprint at: https://arxiv.org/abs/2003.07798

Questions?#

Find us on Slack: https://pressioteam.slack.com or open an issue on github.