<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Dear DUNE developers,</p>
    <p><br>
    </p>
    <p>I would like to draw your attention to a newly introduced
      experimental <code data-sourcepos="16:55-16:66">BCRSMatrix</code> which
      can be found in the development branch of <font face="monospace">dune-istl</font>
      under the <font face="monospace">Dune::Experimental</font> namespace (as
      decided in our last development meeting). The main motivation is
      that this matrix should be faster on memory bound problems due to
      its reduced memory requirements.</p>
    <p><br>
    </p>
    <p>The main improvements over our current <code
        data-sourcepos="16:55-16:66">BCRSMatrix</code> version are:</p>
    <ul>
      <li data-sourcepos="5:1-5:130">Column indices can be chosen at
        compile time, with a default of <code
          data-sourcepos="5:67-5:74">uint32</code> which saves about 25%
        of memory usage on flat matrices.</li>
      <li data-sourcepos="6:1-6:84">Row offsets are now part of the
        shared pattern, and are now stored more compactly.</li>
      <li data-sourcepos="7:1-7:250">Sparse patterns are now an external
        class with a slim interface for general patterns, allowing the
        pattern to be shared with other classes, e.g. for
        mixed-precision algorithms, and to simplify implementation of
        dense, banded, and diagonal matrices.</li>
      <li data-sourcepos="8:1-8:151">There are two separate builder
        classes for sparse pattern creation, making the matrix itself
        much smaller, which is important for sparse-sparse matrices.</li>
      <li data-sourcepos="9:1-9:143">These sparse pattern builders have
        proper buffer growth and compression, removing the need of the
        overflow map or scattered memory allocations.</li>
      <li data-sourcepos="10:1-10:71">Full support of move semantics
        with much better exception guarantees.</li>
      <li data-sourcepos="11:1-11:72">Full support of stateful
        allocators, even on move and swap operations.</li>
      <li data-sourcepos="12:1-13:0">Follows the <a
          data-sourcepos="12:15-12:108"
href="https://en.cppreference.com/cpp/named_req/AllocatorAwareContainer"
          rel="nofollow noreferrer noopener" target="_blank"><em
            data-sourcepos="12:16-12:40">AllocatorAwareContainer</em></a>
        named requirement from the standard library, thus propagating
        allocators to its stored objects.</li>
    </ul>
    <p data-sourcepos="16:1-16:118" dir="auto">It is designed to be an
      almost drop-in replacement of <code data-sourcepos="16:55-16:66">BCRSMatrix</code>
      with a few caveats that are usually easy to modify:</p>
    <ul data-sourcepos="18:1-27:196" dir="auto">
      <li data-sourcepos="18:1-18:117">Rows are proxy objects that are
        generated on-the-fly, this means that they cannot be bound to
        non-const references.</li>
      <li data-sourcepos="19:1-19:190">Row and const row iterators are
        different, respecting const correctness. This may cause some
        issues in code that used the relaxed const correctness
        guarantees of the current <code data-sourcepos="19:169-19:179">BCRMatrix</code>
        iterators.</li>
      <li data-sourcepos="20:1-20:232">The matrix does not store any
        values during the patter formation. Hence, in the case of
        implicit build mode, only default initialized blocks are
        accepted. For instance, this currently affects ILU(t) when t !=
        0. </li>
      <li data-sourcepos="21:1-21:69">The row-wise build mode has
        different begin and end iterator types.</li>
      <li data-sourcepos="22:1-22:122">The <code
          data-sourcepos="22:7-22:17">setSize()</code> method should be
        used <em data-sourcepos="22:41-22:47">after</em> selecting the
        build mode and <i>before</i> the pattern construction is
        finalized.</li>
      <li data-sourcepos="23:1-23:80">The <code
          data-sourcepos="23:7-23:11">N()</code> and <code
          data-sourcepos="23:17-23:21">M()</code> methods are not
        available during the pattern construction.</li>
      <li data-sourcepos="24:1-24:142">The build mode becomes <code
          data-sourcepos="24:26-24:45">BuildMode::unknown</code> after
        the pattern is built, meaning that it needs to be reset before
        constructing a new pattern.</li>
      <li data-sourcepos="25:1-25:44">Setting a build mode cleans up the
        matrix.</li>
      <li data-sourcepos="26:1-26:55">There is no <code
          data-sourcepos="26:15-26:26">BuildStage</code> and their
        related functions.</li>
      <li data-sourcepos="27:1-29:0">There is no one-before iterators as
        they would be undefined behavior (see <a
href="https://gitlab.dune-project.org/core/dune-common/-/work_items/430"
          title="(beforeBegin, beforeEnd] range idiom is not standard"
          class="gfm gfm-work_item"
data-original="https://gitlab.dune-project.org/core/dune-common/-/work_items/430"
          data-link="false" data-link-reference="true"
          data-work-item="5894" data-project="133" data-iid="430"
          data-namespace-path="core/dune-common"
          data-project-path="core/dune-common"
          data-work-item-type="issue" data-container="body"
          data-placement="top" data-reference-type="work_item"
          data-popover-listener-added="true">dune-common#430</a>).</li>
    </ul>
    <p><br>
    </p>
    <p>If you try it out and find issues, please report them by opening
      an issue in our GitLab or (equivalently) by sending an email to
      dune-istl at dune-project.org.</p>
    <p><br>
    </p>
    <p>Happy coding!</p>
    <p>Santiago</p>
    <p><br>
    </p>
  </body>
</html>