Project Proposal

Name of Project: Trilinos
Project Description

The Trilinos project is a community of developers, users and user-developers focused on collaborative creation of algorithms and enabling technologies within an object-oriented software framework for the solution of large-scale, complex multi-physics engineering and scientific problems on new and emerging high-performance computing (HPC) architectures. Trilinos is composed of packages addressing various computational needs of engineering and scientific simulations, including basic linear algebra, utilities for finite-element analysis, suite of common services, partitioning and load balancing, eigensolvers, linear solvers, preconditioners, automatic differentiation, discretization utilities, nonlinear/transient/optimization solvers, and a collection of interfaces and adapters.

Statement on Alignment with High Performance Software Foundation's Mission

Trilinos's Philosophy – "The Trilinos project was established to address two important needs: (1) bringing teams of library developers together in order to leverage commonalities and produce compatible software components, formally called packages and (2) to amortize the cost and efforts associated with more formal software engineering requirements. With a modest level of coordination and without unduly compromising package team autonomy, Trilinos project members could leverage each other’s efforts, consolidate commonly needed tools, make packages compatible, and define a common set of software engineering tools and processes." -- Heroux and Willenbring, "A new overview of the Trilinos project", Scientific Programming 20 (2012) 83–88.

From its inception in 2001, Trilinos has been a federated system of software packages dedicated to continuous improvement, providing essential capabilities for applications within the High Performance Computing (HPC) community. This community comprises over 140 current members with over 500 contributors from government laboratories and academia institutions across more than 10 countries. As an early exemplar of a "team of teams", Trilinos has consistently embraced open-source principles such as collaboration, community engagement, innovation, accessibility, interoperability, quality, reliability, and sustainability. Moving forward Trilinos will remain committed to these principles, fostering broader adoption within the HPC community across a diverse set of platforms and architectures.

Project Website (please provide a link)

https://trilinos.org/ https://github.com/trilinos

Code of Conduct (please provide a link)

Code of Conduct

Governance Practices (please provide a link)

Trilinos Technical Charter Trilinos Governance

Sponsor from the High Performance Software Foundation's Technical Advisory Committee

Todd Gamblin (@tgamblin) and Christian Trott (@crtrott)

What is the project's solution for source control?

GitHub

What is the project's solution for issue tracking?

GitHub

Please list all external dependencies and their license
1. Trilinos has two basic external dependencies for all packages:
  1. BLAS implementations (e.g., OpenBLAS [BSD])
  2. MPI implementations (e.g., OpenMPI [BSD])
2. Note that individual packages have their own licenses, and some software may have separate licenses. The majority are BSD License.
  1. Trilinos Infrastructure: BSD-3-Clause
  2. Adelus: BSD-3-Clause
  3. Amesos: LGPL-2.1-or-later
  4. Amesos2: BSD-3-Clause (Basker LGPL-2.1-or-later; KLU2: LGPL-2.1-or-later)
  5. Anasazi: BSD-3-Clause
  6. Aztecoo: BSD-3-Clause
  7. Belos: BSD-3-Clause
  8. Common:
    1. SuiteSparse:
      1. AMD: BSD 3-clause
      2. BTF: LGPL-2.1-or-later
      3. CAMD: BSD 3-clause
      4. CCOLAMD: BSD 3-clause
      5. CHOLMOD: LGPL-2.1-or-later
      6. COLAMD: BSD 3-clause
      7. KLU: LGPL-2.1-or-later
      8. PARAKLETE: LGPL-2.1-or-later
  9. Compadre: BSD-2-Clause
  10. Epetra: BSD-3-Clause
  11. EpetraExt: BSD-3-Clause
  12. Galeri: BSD-3-Clause
  13. Ifpack: BSD-3-Clause
  14. Ifpack2: BSD-3-Clause
  15. Intrepid: BSD-3-Clause
  16. Intrepid2: BSD-3-Clause (Nektar: MIT License)
  17. Isorropia: BSD-3-Clause
  18. Kokkos: Apache-2.0 WITH LLVM-exception
  19. Kokkos Kernels: Apache-2.0 WITH LLVM-exception
  20. Krino: BSD-3-Clause
  21. MiniTensor: BSD-3-Clause
  22. ML: LGPL-2.1-or-later
  23. MueLu: BSD-3-Clause
  24. New Package: LGPL-2.1-or-later
  25. NOX: BSD-3-Clause
  26. NOX/LOCA: BSD-3-Clause
  27. Pamgen: LGPL-2.1-or-later
  28. Panzer: BSD-3-Clause
  29. Percept: BSD-3-Clause (Intrepid, Shards, MOAB, MESQUITE: LGPL-2.1-or-later)
  30. Phalanx: BSD-3-Clause
  31. Piro: BSD-3-Clause
  32. Pliris: BSD-3-Clause
  33. PyTrilinos: BSD-3-Clause
  34. PyTrilinos2: BSD-3-Clause
  35. ROL: BSD-3-Clause
  36. RTOp: BSD-3-Clause
  37. Sacado: LGPL-2.1-or-later (GTest - BSD-3-Clause and Apache-2.0 licenses)
  38. SEACAS: BSD-3-Clause (various other licenses: Boost Software License, Version 1.0, MIT License, Apache License 2.0)
  39. Shards: BSD-3-Clause
  40. ShyLU: BSD-3-Clause
  41. ShyLU/ShyLU_dd/Core: BSD-3-Clause
  42. ShyLU_Node/Tacho: BSD-2-Clause (GTest - BSD-3-Clause)
  43. STK: BSD-3-Clause
  44. Stokhos: BSD-3-Clause (Nvidia: Apache License, Version 2.0)
  45. Stratimikos: BSD-3-Clause
  46. Teko: BSD-3-Clause
  47. Tempus: BSD-3-Clause
  48. Teuchos: BSD-3-Clause (LAPACK: BSD License)
  49. Thyra: BSD-3-Clause (GNU GLOBAL: GNU General Public License (GPL))
  50. Tpetra: BSD-3-Clause
  51. TrilinosCouplings: BSD-3-Clause
  52. Triutils: BSD-3-Clause
  53. Xpetra: BSD-3-Clause
  54. Zoltan: BSD-3-Clause
  55. Zoltan2: BSD-3-Clause (Sphynx - BSD-3-Clause)
3. Depending on the package:
  1. Required dependencies:
    1. Boost: Boost Software License 1.0
    2. CDT: Mozilla Public License (MPL) 2.0
    3. LAPACK: BSD License
    4. Matio: BSD 2-Clause "Simplified" License
    5. Netcdf: NetCDF license
    6. X11: MIT License
  2. Optional dependencies:
    1. Vendor toolchains (CUDA, ROCm, AMD with various licenses)
    2. ADIOS2: Apache License 2.0
    3. ARPREC: BSD-3-Clause
    4. AmgX: NVIDIA Software License
    5. ArrayFireCPU: BSD License
    6. Avatar: Apache License 2.0
    7. BLACS: BSD License
    8. BinUtils: GNU General Public License (GPL)
    9. Boost: Boost Software License 1.0
    10. CAMAL: Apache License 2.0
    11. CASK: MIT License
    12. CGNS: CGNS License (derived from LGPL)
    13. CSparse: GNU General Public License (GPL)
    14. Catalyst2: Commercial?
    15. Cereal: BSD License
    16. Cholmod: GNU Lesser General Public License (LGPL)
    17. Clp: Common Public License Version 1.0
    18. Cusp: MIT License
    19. DLlib: Boost Software License - Version 1.0
    20. DataWarp: Cray?
    21. Eigen: Mozilla Public License 2.0
    22. ExodusII: BSD License
    23. Faodel: MIT License
    24. GLPK: GNU General Public License (GPL)
    25. HDF5: BSD License
    26. HIPS: MIT License
    27. HWLOC: BSD License
    28. HYPRE: MIT license and the Apache License (Version 2.0)
    29. LAPACK: BSD License
    30. Lemon: GNU Lesser General Public License (LGPL)
    31. MAGMASparse: BSD License
    32. MATLAB: Proprietary License (MathWorks)
    33. MATLABLib: Proprietary License (MathWorks)
    34. METIS: Apache License Version 2.0
    35. MF: Common Public License Version 1.0
    36. MKL: Proprietary License (Intel)
    37. MUMPS: MIT License
    38. Nemesis: BSD License
    39. OVIS: BSD License
    40. OpenNURBS: GNU General Public License v2.0
    41. Oski: BSD License
    42. PAPI: MIT License
    43. PARDISO: Proprietary License
    44. PARDISO_MKL: Proprietary License (Intel)
    45. PETSC: BSD License
    46. PaToH: Apache License Version 2.0
    47. ParMETIS: Apache License Version 2.0
    48. Pnetcdf: NetCDF license
    49. Pthread: (various vendor licenses)
    50. PuLP: Solderpad Hardware License
    51. QD: MIT License
    52. QT: GNU General Public License (GPL) or Commercial License
    53. QTHREAD: GNU General Public License (GPL) or Commercial License
    54. SARMA: BSD License
    55. SCALAPACK: BSD License
    56. SPARSKIT: Commercial?
    57. STRUMPACK: BSD License
    58. Scotch: CeCILL-C free/libre software license
    59. SuperLU: BSD License
    60. SuperLUDist: BSD License
    61. SuperLUMT: BSD License
    62. TAUCS: TAUCS License
    63. TBB: Apache License 2.0
    64. Thrust: Apache License 2.0
    65. TopoManager: Apache License 2.0
    66. UMFPACK: GNU General Public License (GPL)
    67. VTune: Proprietary License (Intel)
    68. Valgrind: GNU General Public License (GPL)
    69. ViennaCL: ViennaCL-1.7.1
    70. Zlib: zlib License
    71. mlpack: BSD License
    72. pebbl: BSD License
    73. qpOASES: GNU Lesser General Public License (LGPL)
    74. quadmath: GNU General Public License (GPL)
    75. y12m: NetCDF license
    76. yamlcpp: MIT License
4. Required dependencies for tests:
  1. MPI implementations (e.g., OpenMPI [BSD])
  2. Netcdf: NetCDF license
5. Optional dependencies for tests:
  1. Vendor toolchains (CUDA, ROCm, AMD with various licenses)
  2. ADIC: MIT License
  3. ADOLC: Eclipse Public License -v 1.0
  4. Cholmod: GNU Lesser General Public License (LGPL)
  5. HDF5: BSD License
  6. HYPRE: MIT license and the Apache License (Version 2.0)
  7. LAPACK: BSD License
  8. METIS: Apache License Version 2.0
  9. MKL: Proprietary License (Intel)
  10. MPI implementations (e.g., OpenMPI [BSD])
  11. OVIS: BSD License
  12. PETSC: BSD License
  13. PaToH: Apache License Version 2.0
  14. ParMETIS: Apache License Version 2.0
  15. Pthread: (various vendor licenses)
  16. PuLP: Solderpad Hardware License
  17. QD: MIT License
  18. QTHREAD: GNU General Public License (GPL) or Commercial License
  19. SARMA: BSD License
  20. SPARSKIT: Commercial?
  21. Scotch: CeCILL-C free/libre software license
  22. SuperLU: BSD License
  23. TopoManager: Apache License 2.0
  24. yamlcpp: MIT License
Please describe your release methodology and mechanics
1. The HEAD on Trilinos's master branch is a fully tested and "ready for use" commit, and can be used for any release. We tag releases using Semantic versioning approximately every three months with GitHub (three minor releases and one annual major release). Pull Requests (PRs) can be labelled to be included in the release notes.
2. The release process is completed using the "Trilinos Release Checklist", which briefly includes creation of a branch for release, update the version numbering, setup the release PR testing, tag the release, announce the release to the Trilinos community, and add release to the Trilinos Spack package.py.
Please describe Software Quality efforts (CI, security, auditing)
1. Continuous Integration (CI):
  1. Trilinos's CI requires Pull Request (PR) and Master Merge (MM) testing prior to being committed to the develop and master branches respectively. This testing encompasses a variety of builds (e.g., compilers, MPI, release, debug, C++ standard, platforms, UVM, parallel/serial, static/shared, numerical types, and many other optional flags) and tests (e.g., individual package tests and Trilinos infrastructure tests). Pull Requests (PRs) are merged to the develop branch upon passing this testing. On a weekly basis the develop branch is merged to the master branch after passing the MM testing, which includes additional builds. Additionally, Nightly builds provides testing that are expensive and/or under development for PR and MM testing (e.g., new platforms, compilers, C++ standards).
2. Security:
  1. Trilinos has a defined security policy and reporting process.
  2. Trilinos reports its OpenSSF Scorecard, and run CodeQL on a limited number of packages but it is expanding.
3. Auditing:
  1. As part of funding from the Department of Energy (DOE), Trilinos is required to complete an audit (ISO 9001 certified) of its software quality every 3 years. Trilinos has been part of this auditing process since 2008, and covers various aspects of software development (e.g., project management, software engineering, software verification, and training).
Please list the project's leadership team
1. The Technical Steering Committee (TSC) has two groups:
  1. Operational Leadership maintains CI/CD processes and develops software to meet application needs. The current members are:
    1. Curtis Ober (SNL) (Trilinos Product Owner) -- GitHub handle: ccober6
    2. Sam Browne (SNL) (DevOps Lead) -- GitHub handle: sebrowne
    3. Roger Pawlowski (SNL) (Core Area Lead) -- GitHub handle: rppawlo
    4. Christian Glusa (SNL) (Solvers Area Lead) -- GitHub handle: cgcgcg
    5. Mauro Perego (SNL) (Discretization and Analysis Area Lead) -- GitHub handle: mperego
  2. Strategic Leadership primarily defines and develops Trilinos strategic research directions to support future application needs. The current members are:
    1. Eric Phipps (SNL) -- GitHub handle: etphipp
    2. Siva Rajamanickam (SNL) -- GitHub handle: srajama1
    3. Heidi Thornquist (SNL) -- GitHub handle: hkthorn
    4. Jim Willenbring (SNL) -- GitHub handle: jwillenbring
    5. Michael Wolf (SNL) -- Github handle: mmwolf
  3. Package Owners lead the package team in performing research and development, and coordinating with other Trilinos packages.
Please list the project members with access to commit to the mainline of the project
1. PRs can be created by any Trilinos developer or contributor, but PR Testing can only be initiated by Pretest-Inspectors who review and approved the PR. Membership to the Pretest-Inspectors GitHub team is controlled by the Trilinos Leadership.
2. Trilinos has a very open policy on who is included in the Pretest-Inspectors team (currently 81 members) and usually includes leadership, package leads and developers. Currently though it is limited to Sandians due to security concerns related to initiating computing sources. It is hoped that this restriction will be removed in the near future.
Please describe the project's decision-making process
1. Given Trilinos's two-level federated model, package teams independently make decisions regarding the research, development, and implementation of their package's software and processes. These teams are expected to adhere to the accepted processes and norms of the open-source community, including those established by the Linux Foundation, HPSF, and Trilinos itself.
2. Decisions within package teams are typically reached through developer consensus, with co-team members engaging in discussions, reviews, and approvals via the pull request (PR) process. However, decisions related to package interoperability, compatibility, and common software engineering tools and processes (CI/CD) are managed by the Trilinos Leadership (i.e., TSC), and this often involves package leads due to their expertise and the impact on their respective packages.
3. Additionally, the Trilinos Leadership is responsible for reviewing applications for new packages and their inclusion in Trilinos. The Trilinos Leadership also formulates policies to encourage package teams to enhance software quality, sustainability, and security.
4. Discussion topics and decisions are presented and discussed by the Trilinos Leadership regularly (~ 3 weeks) at Trilinos Developers Meetings and at the annual Trilinos Users/Developer Group (TUG) Meeting.
What is the maturity level of your project?
1. We expect to join at the “Established” stage. Currently, we do not meet the requirement that no more than 50% of our leadership team come from the same institution for “Core” membership.
2. Trilinos packages have their own maturity level and growth rate. However, a majority of the packages meet all the criteria of the Established Stage, and many of the Core Stage.
3. Acceptance Criteria:
  1. Sandbox Stage:
    1. [x] Meet all requirements to be a Linux Foundation project
    2. [x] Have 2 TAC sponsors to champion the project & provide mentorship as needed
    3. [x] Submit a proposal for membership and present it at a meeting of the TAC
    4. [x] Have a charter document with an intellectual property policy that leverages open licenses, including, in the case of contributions of code, the use of one or more licenses approved as “open” by the Open Source Initiative. The staff of the High Performance Software Foundation can assist projects in preparing a technical charter following the High Performance Software Foundation’s standard template.
    5. [x] Have a code of conduct (part of default governance for LF – there is a template)
    6. [x] Upon acceptance, projects must list their status prominently on their website/README
  2. Established Stage:
    1. [x] Document that it is being used successfully in production by at least three independent end users which, in the TAC’s judgment, are of adequate quality and scope.
    2. [x] Demonstrate development processes (e.g., use of pull requests, code review, testing, CI) that lower barriers to contribution and ensure software quality necessary for increased adoption.
    3. [x] Demonstrate a substantial ongoing flow of commits and merged contributions.
    4. [ ] Since these metrics can vary significantly depending on the type, scope, and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria.
    5. [ ] Receive a 2/3 majority vote of the TAC to move to the Established Stage.
  3. Core Stage:
    1. [ ] Have a defined governing body of at least 4 or more members (owners and core maintainers), of which no more than 1/2 of whom are affiliated with the same employer. No single institution may control a voting majority of the governing body.
    2. [x] Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.
    3. [x] Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
    4. [x] Explicitly defined security reporting and incident mitigation processes, as appropriate to the security risks of the project.
    5. [x] Explicitly defined project governance and committer process.
    6. [x] Provide evidence of widespread adoption in the HPC ecosystem or in some important component thereof.
    7. [ ] Receive a 2/3 majority vote from the TAC to move to Core stage. Projects can move directly from Sandbox to Core if they can demonstrate sufficient maturity and have met all requirements.
  4. Emeritus Stage:
    1. [ ] 2/3 vote of the TAC.
    2. [ ] Approval from project ownership.
Please list the project's official communication channels
1. Issues and discussions take place on GitHub.
2. Email Lists(trilinos-announce@trilinos.org and trilinos-developers@trilinos.org)
Please list the project's social media accounts

Trilinos-Official - YouTube

Please describe any existing financial sponsorships

All Trilinos leadership, package leaders and developers are financed by their respective institutions. Currently, many contributors receive funding from the Department of Energy (DOE). This support is subject to annual renewal. However, given that many DOE-supported applications rely on Trilinos for their capabilities, it is likely that this support will continue for the foreseeable future.

Please describe the project's infrastructure needs or requests
1. Trilinos is very interested in CI support, particularly on external platforms of various architectures.
2. Trilinos is also interested in broadening its annual user meeting to the larger HPC community, possibly with other HPSF projects.
3. Trilinos would also be interested in refreshing its website.

hpsfoundation / tac

[Project Proposal] Trilinos #12

Project Proposal