Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T Trilinos
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 936
    • Issues 936
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 22
    • Merge requests 22
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • James Willenbring
  • Trilinos
  • Merge requests
  • !5115

Open
Created May 06, 2019 by James Willenbring@jmwilleMaintainer
  • Report abuse
Report abuse

Tpetra: "New RTI" (Reduction Transform Interface), Part 1 (for_each, transform)

  • Overview 2
  • Commits 45
  • Changes 11

Created by: mhoemmen

@trilinos/tpetra

Description

Tpetra once had something called the Reduction Transform Interface (RTI). It let users apply a function to each entry of one or two (or three, I think) Tpetra::Vectors, and then possibly end with a reduction over the output Vector.

This commit starts anew with RTI, by adding the following features:

  1. withLocalAccess: Access the local data of a Tpetra::)Multi)Vector in a given memory space -- a declarative replacement for DualView-style functions
  2. for_each: Works like std::for_each, but for Tpetra::(Multi)Vector
  3. transform: Works like unary or binary std::transform, but for Tpetra::(Multi)Vector

(2) and (3) use (1). All of these have extension points so that they can be adapted for other objects, such as CrsGraph or CrsMatrix.

Motivation and Context

Users want to apply functions entrywise to a Vector or MultiVector. They want to get at the local data, and they want Tpetra to handle the sync and modify flag stuff for them. Tpetra wants the power to do things like lazy allocation (see #333) that go beyond what Kokkos::DualView allows. Tpetra wants to protect users from holding on to owning Kokkos::View that really belong to Tpetra objects, because that can cause bugs (e.g., if the mesh that produced the linear system has changed) and unnecessary memory usage.

Next steps

  1. Add transform_reduce (the "R" in "RTI")
  2. Think about how to do kernel fusion with a mixture of Vector and CrsMatrix (or at least provide a "residual" interface)

Related Issues

  • Closes: #3471
  • Related to #333, #364, #381, #415, #768, #1424, #1896
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: mhoemmen:VectorHarness5