You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: Viskores is transitioning from a previous name: VTK-m. Some of the
answers in this form refer to features of VTK-m that will be moved to the
new name/repo Viskores.
1. Name of Project
Viskores
2. Project Description
Viskores is a toolkit of scientific visualization algorithms for computer
processor architectures that require running many concurrent threads to
maintain high computational throughput such as a GPU. Viskores supports the
fine-grained concurrency for data analysis and visualization algorithms
required to drive extreme scale computing by providing abstract models for
data and execution that can be applied to a variety of algorithms across
many different processor architectures. Viskores also comes with many
classic and modern scientific visualization algorithms.
3. Statement on Alignment with High Performance Software Foundation's Mission
GPUs and other processors that support many threads are an important
component of modern HPC systems. Such accelerator processors are installed
on about 1/3 of all machines listed in the TOP500
list. As such, efficient visualization and analysis algorithms are critical
for in situ and large-scale analysis.
Viskores provides the scientific visualization algorithms needed on modern
HPC systems. Viskores is designed to be integrated into other software and
currently integrates with Ascent, ParaView, VisIt, and ADIOS. As
such, Viskores plays an important role in the HPC software ecosystem.
The rendering module contains multiple rendering implementations
including standalone rendering code. The rendering module also
includes (optionally built) OpenGL rendering classes.
The OpenGL rendering classes require that you have a extension
binding library and one rendering library. A windowing library is
not needed except for some optional tests.
11. Please describe your release methodology and mechanics
Viskores is released on a roughly 6-month cadence although this is often
adjusted as needed by customers. We create a branch for each release,
and each release is preceded by one or more release candidates.
Each release candidate gets tagged and packaged like any other release.
These release candidates are open for community testing, and when no
problems are found for a particular release candidate, the same code is
provided as the next release. Branches to several past releases are
maintained to allow patching multiple releases that are in active use.
The full release process is documented in the Release Process guide.
All contributions to Viskores must be submitted as a pull request through
GitHub. Before any pull request can be merged into the development or any
release branch, it must be reviewed by an independent developer and it must
pass regression testing.
Code reviews are performed via the GitHub PR interface. Reviewers help
check for correctness as well as verify the code satisfies Viskores
testing, documentation, and style guidelines. Code reviews also help ensure
against bad-faith contributions.
Regression testing is built into the CI infrastructure of pull requests.
The pull request automatically launches jobs that in turn execute build
and/or run phases in container images. Regression tests are automatically
run on a variety of architectures including Windows, Mac OS, and multiple
distributions of Linux. Builds include multiple compiler versions including
GCC and Clang versions. Viskores is also tested specifically on Cuda and
HIP architectures. In addition to the standard set of regression tests, a
special job runs a select set of benchmarks to help ensure major
performance regressions do not happen.
Note: In the transition from VTK-m, the Viskores CI infrastructure is
being rebuilt, in part to take advantage of the gitlab.spack.io testing services.
13. Please list the project's leadership team
Viskores Technical Steering Committee comprises the following members (with
their GitHub user ID):
15. Please describe the project's decision-making process
We aim for consensus-driven decision making, and we will resort to votes of
the TSC when we are unable to reach consensus.
Reviews of pull requests must be approved and merged by a committer with
appropriate access although the review itself may be delegated to another
contributor.
16. What is the maturity level of your project?
We aim to join the HPSF as a Sandbox stage project while in the transition
from VTK-m to Viskores. Although we have a mature process for continuous
integration, software contributions, and release management, we will
revisit these processes as part of the transition.
We hope to transition to a Established stage project shortly after the
transition to the new name. Viskores has over 70 contributors spread across
20 organizations.
17. Please list the project's official communication channels
Bi-weekly public meetings
Email mailing list (to be transitioned from VTK-m)
GitLab issues and MRs (to be transitioned from VTK-m)
18. Please list the project's social media accounts
N/A
19. Please describe any existing financial sponsorships
Contributors are primarily paid by their own institution to work on
Viskores. Most of the support funding comes from DOE/SC Software
Sustainability funds informally known as OASIS. This and other
application-facing support comes from the RAPIDS2 SciDAC project.
Here is a rough breakdown of the expected funding for Viskores.
The top entry is funds dedicated to Viskores stewardship. The remaining
funds represent the pay-as-you-go work as projects contribute to
Viskores for their specific needs. These funds are more speculative.
Time
Lab
Description
0.33 FTE
ORNL
Stewardship
0.15 FTE
ORNL
SciDAC
0.10 FTE
ORNL
NCCS
0.10 FTE
LBL
LDRD
0.15 FTE
LANL
ASC
0.05 FTE
Kitware
Stewardship (in kind)
0.10 FTE
LLNL
Stewardship (in kind)
0.10 FTE
LLNL
ASQ
20. Please describe the project's infrastructure needs or requests
Viskores is interested in support for its CI system, particularly with
regard to testing on various compute devices. (Much of this support will
likely come from the University of Oregon testing platform currently used
for Spack. Thus, this might not be an expense on HPSF directly, but would
unlikely be made available without the HPSF.) We would also ask for support
if Viskores outgrows GitHub free plans.
Viskores is also interested in HPSF support for communication materials
such as the maintenance of web pages and videoconferencing accounts. We are
also interested in regular hackathon meetings for code sprints.
Evidence: The LF accepted the initially empty Viskores repository.
Have 2 TAC sponsors to champion the project & provide mentorship as
needed
Todd Gamblin and Damien Lebrun-Grandie
Submit a proposal for membership and present it at a meeting of the
TAC
Evidence: This proposal.
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.
Project Proposal
Note: Viskores is transitioning from a previous name: VTK-m. Some of the
answers in this form refer to features of VTK-m that will be moved to the
new name/repo Viskores.
1. Name of Project
Viskores
2. Project Description
Viskores is a toolkit of scientific visualization algorithms for computer
processor architectures that require running many concurrent threads to
maintain high computational throughput such as a GPU. Viskores supports the
fine-grained concurrency for data analysis and visualization algorithms
required to drive extreme scale computing by providing abstract models for
data and execution that can be applied to a variety of algorithms across
many different processor architectures. Viskores also comes with many
classic and modern scientific visualization algorithms.
3. Statement on Alignment with High Performance Software Foundation's Mission
GPUs and other processors that support many threads are an important
component of modern HPC systems. Such accelerator processors are installed
on about 1/3 of all machines listed in the TOP500
list. As such, efficient visualization and analysis algorithms are critical
for in situ and large-scale analysis.
Viskores provides the scientific visualization algorithms needed on modern
HPC systems. Viskores is designed to be integrated into other software and
currently integrates with Ascent, ParaView, VisIt, and ADIOS. As
such, Viskores plays an important role in the HPC software ecosystem.
4. Project Website (please provide a link)
5. Code of Conduct (please provide a link)
Viskores/viskores#1
6. Governance Practices (please provide a link)
7. Two Sponsors from the High Performance Software Foundation's Technical Advisory Committee
Todd Gamblin and Damien Lebrun-Grandie
8. What is the project's solution for source control?
GitHub
9. What is the project's solution for issue tracking?
GitHub Issues
10. Please list all external dependencies and their license
Requirements for compiling:
The Viskores source contains snapshots of the following:
Optional dependencies are:
hipcc when using Kokkos device adapter with HIP (ROCM>=6).
including standalone rendering code. The rendering module also
includes (optionally built) OpenGL rendering classes.
binding library and one rendering library. A windowing library is
not needed except for some optional tests.
Viskores has been tested on the following configurations:c
11. Please describe your release methodology and mechanics
Viskores is released on a roughly 6-month cadence although this is often
adjusted as needed by customers. We create a branch for each release,
and each release is preceded by one or more release candidates.
Each release candidate gets tagged and packaged like any other release.
These release candidates are open for community testing, and when no
problems are found for a particular release candidate, the same code is
provided as the next release. Branches to several past releases are
maintained to allow patching multiple releases that are in active use.
The full release process is documented in the Release Process guide.
12. Please describe Software Quality efforts (CI, security, auditing)
All contributions to Viskores must be submitted as a pull request through
GitHub. Before any pull request can be merged into the development or any
release branch, it must be reviewed by an independent developer and it must
pass regression testing.
Code reviews are performed via the GitHub PR interface. Reviewers help
check for correctness as well as verify the code satisfies Viskores
testing, documentation, and style guidelines. Code reviews also help ensure
against bad-faith contributions.
Regression testing is built into the CI infrastructure of pull requests.
The pull request automatically launches jobs that in turn execute build
and/or run phases in container images. Regression tests are automatically
run on a variety of architectures including Windows, Mac OS, and multiple
distributions of Linux. Builds include multiple compiler versions including
GCC and Clang versions. Viskores is also tested specifically on Cuda and
HIP architectures. In addition to the standard set of regression tests, a
special job runs a select set of benchmarks to help ensure major
performance regressions do not happen.
Note: In the transition from VTK-m, the Viskores CI infrastructure is
being rebuilt, in part to take advantage of the
gitlab.spack.io testing services.
13. Please list the project's leadership team
Viskores Technical Steering Committee comprises the following members (with
their GitHub user ID):
14. Please list the project members with access to commit to the mainline of the project
15. Please describe the project's decision-making process
We aim for consensus-driven decision making, and we will resort to votes of
the TSC when we are unable to reach consensus.
Reviews of pull requests must be approved and merged by a committer with
appropriate access although the review itself may be delegated to another
contributor.
16. What is the maturity level of your project?
We aim to join the HPSF as a Sandbox stage project while in the transition
from VTK-m to Viskores. Although we have a mature process for continuous
integration, software contributions, and release management, we will
revisit these processes as part of the transition.
We hope to transition to a Established stage project shortly after the
transition to the new name. Viskores has over 70 contributors spread across
20 organizations.
17. Please list the project's official communication channels
18. Please list the project's social media accounts
N/A
19. Please describe any existing financial sponsorships
Contributors are primarily paid by their own institution to work on
Viskores. Most of the support funding comes from DOE/SC Software
Sustainability funds informally known as OASIS. This and other
application-facing support comes from the RAPIDS2 SciDAC project.
Here is a rough breakdown of the expected funding for Viskores.
The top entry is funds dedicated to Viskores stewardship. The remaining
funds represent the pay-as-you-go work as projects contribute to
Viskores for their specific needs. These funds are more speculative.
20. Please describe the project's infrastructure needs or requests
Viskores is interested in support for its CI system, particularly with
regard to testing on various compute devices. (Much of this support will
likely come from the University of Oregon testing platform currently used
for Spack. Thus, this might not be an expense on HPSF directly, but would
unlikely be made available without the HPSF.) We would also ask for support
if Viskores outgrows GitHub free plans.
Viskores is also interested in HPSF support for communication materials
such as the maintenance of web pages and videoconferencing accounts. We are
also interested in regular hackathon meetings for code sprints.
Criteria for Sandbox Stage
needed
TAC
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.
is a template)
The text was updated successfully, but these errors were encountered: