Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T Trilinos
  • Project information
    • Project information
    • Activity
    • Labels
    • 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
  • Issues
  • #660

Closed
Open
Created Sep 27, 2016 by James Willenbring@jmwilleMaintainer

Tpetra::CrsGraph: 2- or 3-level thread parallelization of sortAllIndices & mergeAllIndices

Created by: mhoemmen

@trilinos/tpetra Do a 2-level or 3-level thread parallelization of Tpetra::CrsGraph methods sortAllIndices and mergeAllIndices.

This is a "story" because this may call for a thread-parallel segmented sort, or segmented sort-and-merge.

Update (12 Nov 2016): I rewrote this issue to reflect a multiple-step process. See #832. The first step will be a single-level thread parallelization. The second step (likely done at the same time) will be to remove any implicit UVM assumptions that the methods may make. The third step would be this issue, a 2-level or 3-level parallelization that relies on a segmented sort (which does not exist yet; see #662).

Assignee
Assign to
Time tracking