.. role:: raw-html-m2r(raw) :format: html .. include:: mydefs.rst pressio-rom =========== 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 across the ``rom``, ``ode``, and ``solvers`` components. Please keep this in mind while browsing the documentation and the code. The supported capabilities of ``pressio-rom`` are included in the table below. Each component (level) of the stack depends on the ones below it. | .. list-table:: :widths: 10 48 42 :header-rows: 1 :align: left * - - Description - Header(s) * - ``rom`` - concepts :raw-html-m2r:`
` (linear) subspaces :raw-html-m2r:`
` Galerkin: steady :raw-html-m2r:`
` Galerkin: unsteady :raw-html-m2r:`
` LSPG: steady :raw-html-m2r:`
` LSPG: unsteady :raw-html-m2r:`
` :raw-html-m2r:`
` - ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :small:`includes all` * - ``ode`` - concepts :raw-html-m2r:`
` explicit steppers :raw-html-m2r:`
` implicit steppers :raw-html-m2r:`
` ``advance_<*>`` fncs :raw-html-m2r:`
` :raw-html-m2r:`
` - ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :small:`includes all` * - ``solvers_nonlinear`` - concepts :raw-html-m2r:`
` Newton method :raw-html-m2r:`
` Gauss-Newton :raw-html-m2r:`
` Lev.-Marq. :raw-html-m2r:`
` :raw-html-m2r:`
` - ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :raw-html-m2r:`
` ```` :small:`includes all` * - ``solvers_linear`` - linear dense (on-node) solvers - ```` These components depend on the `Pressio/pressio-ops `_ header-only library. Get Started ----------- * `Configure pressio-rom `_: (currently) it is a header-only library, so should be trivial * Explore our `end-to-end ROM demos `_ to see ``pressio-rom`` in action and to experiment directly * Explore the `tutorials showing the individual capabilities `_ 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 `_. .. toctree:: :maxdepth: 1 :hidden: configuration keywords .. toctree:: :caption: ROMs :maxdepth: 1 :hidden: ./components/rom_concepts .. toctree:: :caption: ODE :maxdepth: 1 :hidden: ./components/ode_concepts ./components/ode_examples .. toctree:: :caption: Nonlinear solvers :maxdepth: 1 :hidden: ./components/nonlinsolvers_newton ./components/nonlinsolvers_enums ./components/nonlinsolvers_examples .. toctree:: :caption: Linear solvers :maxdepth: 1 :hidden: ./components/linsolvers .. toctree:: :caption: Miscellanea :maxdepth: 1 :hidden: GitHub Repo Open an issue/feature req. license .. Generic programming and concepts -------------------------------- Arguably the main foundation of pressio-rom 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-rom inside a preprocessor directive ``#ifdef PRESSIO_ENABLE_CXX20``. 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++17. 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. .. Read more about `concepts in Pressio `_. .. Here, the term concept does not necessarily refer to the C++ concepts feature introduced in C++20. You can think of it more broadly as "what properties/syntax a type meets, what you can do with it and, also, what a type should definitely satisfy". The message we want to convey is that *"concepts" are a fundamental design part of pressio*. In our documentation, we make the effort to highlight the use of concepts by dedicating to each component of the library a full section to discuss and formalize how concepts are used in that component.