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
  • Issues
  • #606

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

Tpetra::Crs{Graph,Matrix}: Either remove getGlobalNumEntries & getGlobalMaxNumRowEntries, or make them global collectives

Created by: mhoemmen

@trilinos/tpetra @trilinos/amesos2 @trilinos/ifpack2 @trilinos/muelu @trilinos/xpetra @trilinos/zoltan2

Tpetra::CrsGraph and Tpetra::CrsMatrix provide three methods, getGlobalNumDiags, getGlobalNumEntries, and getGlobalMaxNumRowEntries. These methods do not currently have collective semantics. Thus, it must be correct to call them at any time (when the graph / matrix is fillComplete), on any process. This implies that the graph / matrix must compute them via all-reduce at first fillComplete. This increases set-up cost.

Most users don't need to know the global (over all MPI processes in the communicator) number of entries, or diagonal entries. Some users might; for example, Amesos2 might want to know the global number of entries in order to prepare enough space to gather in the matrix for a direct solve. However, those users can do the all-reduce themselves, and save and reuse its result as part of the "symbolic factorization" set-up phase.

Thus, I think it would be good to deprecate and remove these methods. @csiefer2 talked about another option, namely to change the methods to have collective semantics that cache the value on first call and clear the cache at resumeFill (if the graph's structure can change). Please explain which option you would prefer here.

Edit (21 Dec 2016): I changed the issue title, to make clear the consequences of a fix, and edited the text a bit to give affected packages a chance to offer feedback for their preferred solution.

Assignee
Assign to
Time tracking