LLNL’s RADIUSS project—Rapid Application Development via an Institutional Universal Software Stack— aims to broaden usage across LLNL and the open source community of a set of libraries and tools used for HPC scientific application development
About RADIUSS
The RADIUSS project promotes and supports a broad set of open source software developed over many years at Lawrence Livermore National Laboratory (LLNL) for use outside of their primary funding organization and within the broader scientific research community. With these libraries and tools we cover a wide range of features a team would need to develop a modern scientific simulation code, particularly when targeting High Performance Computing (HPC). Each of these products are used in applications that support the LLNL science mission, and will be supported and continuously developed for the foreseeable future. These are not research projects that will simply vanish if a lead developer finds other interests - but well-supported software backed by programs and sponsors, and supplemented with support through the RADIUSS project for broader use and external engagement.
Policies and Guidelines
As part of the RADIUSS project, these open source products follow a set of policies and guidelines (listed below) based on best practices for open source development learned and adopted through years of research and development supporting production software running on the worlds largest supercomputers. Some of these policies were derived directly or indirectly from other similar documents 1 2 3 4 listed at the bottom of this page. By sharing these policies publicly, we hope to encourage others to adopt similar standards for the betterment of the open source software community, and welcome a dialogue on where we could improve.
These policies and guidelines are not meant to be a comprehensive set of recommendations for good software quality assurance (SQA) practices (although many of them do promote that). Instead, these are policies that we feel are particularly important for developers of open source software to follow. We strongly believe that open source software will not succeed by just being “put out there”. These policies are our attempt to capture the things we feel are most important to a successful open source project, beyond just good SQA practices that any software engineer would promote.
We intend to continuously evolve these policies and guidelines in the future. In particular, tools mentioned are not eternal and best practices evolve rapidly, demanding flexibility in our approaches. However, we attempted to make these recommendation as generic as possible, so that they could apply to the various types of projects RADIUSS supports, and likewise may serve to others. While we try not to interfere in project’s management, with found it important and relevant to focus our support effort on a subset of fundamental tools, so that knowledge and practices can easily be shared, and for the sake of interoperability.
RADIUSS and the projects it covers are open-source and primarily (or by now, exclusively) use GitHub for repository management. These policies and guidelines are themselves part of the GitHub repository that automates the building and updating of LLNL’s Software Portal, to which you are welcome to submit an issue or pull request to help us evolve these policies.
Legend
Designates a mandatory point (policy).
Designates a recommended point (guideline).
Headline-only format follows. Click on any header or badge icon for more detailed description
Or try the printer-friendly flat version.
Licensing
New projects must use an OSI-approved, permissive open-source license (e.g., Apache, Apache-2.0 with LLVM exception, MIT, or BSD 3-Clause)
Provide a list of dependencies and their associated licenses in SPDX format.
Existing projects should consider moving to an OSI-approved, permissive open-source license for existing projects (e.g., Apache, MIT, or BSD 3-Clause).
Build
Package your installation and provide automated builds of dependencies using Spack.
Compilable projects (e.g., those written in C++ and/or Fortran) must be buildable with CMake.
Provide build options for production (optimized) and debug deployments.
Packaging
Version number and build characteristics must be easily accessible.
Use a limited, unique, and well-defined symbol, macro, library, and include file namespace.
Use MPI in a way that is compatible with other products.
Version Control
The source code must be version controlled using Git.
Provide a transparent, online contribution process based on pull requests and issues collection.
Documentation
Publish documentation in a web-based format.
Provide a concise description of the project.
Version control your documentation consistent with and alongside your source code.
Provide a documented, reliable way to contact the development team.
Provide and maintain example source code along with documentation.
Provide a documented policy for handling pull requests from external contributors.
Testing and Continuous Integration
Use regression tests in the development process.
Provide a test suite for verifying correctness of build and installation.
Provide a development test suite along with the source code for external contributors.
Use continuous integration (CI).
Continuously check compatibility with different compilers and versions.
Ensure code quality/health in an automated manner.
Portability
Give best effort at portability to common HPC platforms and compiling toolchains.
Support Apple MacOS (Xcode) and Microsoft Windows (Visual Studio).
