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
  • #754

Closed
Open
Created Oct 30, 2016 by James Willenbring@jmwilleMaintainer

Belos: Make it possible to specialize SolverFactory for "native" solvers

Created by: mhoemmen

@trilinos/belos @trilinos/tpetra

This blocks #748 (closed).

We would like to add solvers to Belos that are "native" to a particular linear algebra implementation, in this case Tpetra. "Native" means that the solvers are specialized for Tpetra, and only work with Tpetra linear algebra classes. This lets them take advantage of particular features of the linear algebra, without us needing to extend e.g., MultiVecTraits (which would break users' code that specializes those traits classes for their own linear algebra implementations).

We could handle this via partial specialization of Belos::SolverFactory for Tpetra. SolverFactory lives upstream of Belos' Tpetra specialization, and indeed lives upstream of any linear algebra - specific specialization of Belos' classes. Thus, we would need to declare the partial specialization of SolverFactory in the same header file as Belos' Tpetra adapters. (It must be the same header file, else users and downstream packages would need to change their code to include a new header file.)

To avoid redundant code in SolverFactory, and also to avoid lots of extra includes in a header file (Belos' Tpetra adapters) that many users include, it would be nicer to separate SolverFactory into two parts. The first would build Belos' "generic" solvers, that don't have Tpetra-specific implementations. The second would offer a "hook" via traits class, for a factory of implementations native to the linear algebra.

Assignee
Assign to
Time tracking