diff --git a/_data/quality_dimensions.yml b/_data/quality_dimensions.yml index a1bb3560..fe51488c 100644 --- a/_data/quality_dimensions.yml +++ b/_data/quality_dimensions.yml @@ -1,420 +1 @@ -- abbreviation: compatibility - description: 'Degree to which a product, system or component can exchange information - with other products, systems or components, and/or perform its required functions - while sharing the same common environment and resources. This characteristic - is composed of the following sub-characteristics: - - - **Co-existence** - - - Degree to which a product can perform its required functions efficiently while - sharing a common environment and resources with other products, without detrimental - impact on any other product. - - - **Interoperability** - - - Degree to which a system, product or component can exchange information with - other products and mutually use the information that has been exchanged.' - identifier: https://w3id.org/everse/i/dimensions/compatibility - name: Compatibility - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: fairness - description: 'FAIRness refers to the degree to which research software adheres - to the FAIR principles: Findable, Accessible, Interoperable, and Reusable. - These principles, adapted for research software, aim to enhance the discoverability, - accessibility, interoperability, and reusability of software, thereby maximizing - its value and impact in scientific research.' - identifier: https://w3id.org/everse/i/dimensions/fairness - name: FAIRness - source: - name: Introducing the FAIR Principles for research software - url: https://www.nature.com/articles/s41597-022-01710-x -- abbreviation: flexibility - description: 'Degree to which a product can be adapted to changes in its requirements, - contexts of use or system environment. This characteristic is composed of - the following sub-characteristics: - - - **Adaptability** - - - Degree to which a product or system can effectively and efficiently be adapted - for or transferred to different hardware, software or other operational or - usage environments. - - - **Scalability** - - - Degree to which a product can handle growing or shrinking workloads or to - adapt its capacity to handle variability. - - - **Installability** - - - Degree of effectiveness and efficiency with which a product or system can - be successfully installed and/or uninstalled in a specified environment. - - - **Replaceability** - - - Degree to which a product can replace another specified software product for - the same purpose in the same environment.' - identifier: https://w3id.org/everse/i/dimensions/flexibility - name: Flexibility - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: functional_suitability - created: 03-04-2025 - description: 'This characteristic represents the degree to which a product or - system provides functions that meet stated and implied needs when used under - specified conditions. This characteristic is composed of the following sub-characteristics: - - - **Functional completeness** - - - Degree to which the set of functions covers all the specified tasks and intended - users'' objectives. - - - **Functional correctness** - - - Degree to which a product or system provides accurate results when used by - intended users. - - - **Functional appropriateness** - - - Degree to which the functions facilitate the accomplishment of specified tasks - and objectives.' - identifier: https://w3id.org/everse/i/dimensions/functional_suitability - name: Functional suitability - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: interaction_capability - description: 'Degree to which a product or system can be interacted with by specified - users to exchange information via the user interface to complete specific - tasks in a variety of contexts of use. This characteristic is composed of - the following sub-characteristics: - - - **Appropriateness recognizability** - - - Degree to which users can recognize whether a product or system is appropriate - for their needs. - - - **Learnability** - - - Degree to which the functions of a product or system can be learnt to be used - by specified users within a specified amount of time. - - - **Operability** - - - Degree to which a product or system has attributes that make it easy to operate - and control. - - - **User error protection** - - - Degree to which a system prevents users against operation errors. - - - **User engagement** - - - Degree to which a user interface presents functions and information in an - inviting and motivating manner encouraging continued interaction. - - - **Inclusivity** - - - Degree to which a product or system can be used by people of various backgrounds - (such as people of various ages, abilities, cultures, ethnicities, languages, - genders, economic situations, etc.). - - - **User assistance** - - - Degree to which a product can be used by people with the widest range of characteristics - and capabilities to achieve specified goals in a specified context of use. - - - **Self-descriptiveness** - - - Degree to which a product presents appropriate information, where needed by - the user, to make its capabilities and use immediately obvious to the user - without excessive interactions with a product or other resources (such as - user documentation, help desks or other users).' - identifier: https://w3id.org/everse/i/dimensions/interaction_capability - name: Interaction Capability - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: maintainability - description: 'This characteristic represents the degree of effectiveness and efficiency - with which a product or system can be modified to improve it, correct it or - adapt it to changes in environment, and in requirements. This characteristic - is composed of the following sub-characteristics: - - - **Modularity** - - - Degree to which a system or computer program is composed of discrete components - such that a change to one component has minimal impact on other components. - - - **Reusability** - - - Degree to which a product can be used as an asset in more than one system, - or in building other assets. - - - **Analysability** - - - Degree of effectiveness and efficiency with which it is possible to assess - the impact on a product or system of an intended change to one or more of - its parts, to diagnose a product for deficiencies or causes of failures, or - to identify parts to be modified. - - - **Modifiability** - - - Degree to which a product or system can be effectively and efficiently modified - without introducing defects or degrading existing product quality. - - - **Testability** - - - Degree of effectiveness and efficiency with which test criteria can be established - for a system, product or component and tests can be performed to determine - whether those criteria have been met.' - identifier: https://w3id.org/everse/i/dimensions/maintainability - name: Maintainability - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: open_source_software - description: Open source software is software with source code that anyone can - inspect, modify, and enhance. Research software can be published with or without - open access to the source code. Open access to source code aligns better with - academic research purposes than closed source software; open source software - aligns with the FAIR4RS principles. It allows other researchers to directly - verify the methods used to produce the results published in papers. It also - makes reproducibility much easier. In addition to these research-driven reasons, - publishing research software as open source software can help with long term - maintenance in a cost-effective way, since interested developers can easily - contribute new functionality or fix bugs. Moreover, by integrating with the - greater open source ecosystem, researchers can leverage tools and support - communities already available. As such, for most academic communities with - limited resources, it is also a good choice from a software engineering perspective - identifier: https://w3id.org/everse/i/dimensions/open_source_software - name: Open Source Software - source: - - identifier: https://doi.org/10.5281/zenodo.14204478 - name: EVERSE Reference Framework - url: https://doi.org/10.5281/zenodo.14204478 - - name: What is Open Source? - url: https://opensource.com/resources/what-open-source -- abbreviation: performance_efficiency - description: 'This characteristic represents the degree to which a product performs - its functions within specified time and throughput parameters and is efficient - in the use of resources (such as CPU, memory, storage, network devices, energy, - materials...) under specified conditions. This characteristic is composed - of the following sub-characteristics: - - - **Time behaviour** - - - Degree to which the response time and throughput rates of a product or system, - when performing its functions, meet requirements. - - - **Resource utilization** - - - Degree to which the amounts and types of resources used by a product or system, - when performing its functions, meet requirements. - - - **Capacity** - - - Degree to which the maximum limits of a product or system parameter meet requirements.' - identifier: https://w3id.org/everse/i/dimensions/performance_efficiency - name: Performance Efficiency - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: reliability - description: 'Degree to which a system, product or component performs specified - functions under specified conditions for a specified period of time. This - characteristic is composed of the following sub-characteristics: - - - **Faultlessness** - - - Degree to which a system, product or component performs specified functions - without fault under normal operation. - - - **Availability** - - - Degree to which a system, product or component is operational and accessible - when required for use. - - - **Fault tolerance** - - - Degree to which a system, product or component operates as intended despite - the presence of hardware or software faults. - - - **Recoverability** - - - Degree to which, in the event of an interruption or a failure, a product or - system can recover the data directly affected and re-establish the desired - state of the system.' - identifier: https://w3id.org/everse/i/dimensions/reliability - name: Reliability - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: safety - description: 'This characteristic represents the degree to which a product under - defined conditions avoids a state in which human life, health, property, or - the environment is endangered. This characteristic is composed of the following - sub-characteristics: - - - **Operational constraint** - - - Degree to which a product or system constrains its operation to within safe - parameters or states when encountering operational hazard. - - - **Risk identification** - - - Degree to which a product can identify a course of events or operations that - can expose life, property or environment to unacceptable risk. - - - **Fail safe** - - - Degree to which a product can automatically place itself in a safe operating - mode, or to revert to a safe condition in the event of a failure. - - - **Hazard warning** - - - Degree to which a product or system provides warnings of unacceptable risks - to operations or internal controls so that they can react in sufficient time - to sustain safe operations. - - - **Safe integration** - - - Degree to which a product can maintain safety during and after integration - with one or more components.' - identifier: https://w3id.org/everse/i/dimensions/safety - name: Safety - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: security - description: 'Degree to which a product or system defends against attack patterns - by malicious actors and protects information and data so that persons or other - products or systems have the degree of data access appropriate to their types - and levels of authorization. This characteristic is composed of the following - sub-characteristics: - - - **Confidentiality** - - - Degree to which a product or system ensures that data are accessible only - to those authorized to have access. - - - **Integrity** - - - Degree to which a system, product or component ensures that the state of its - system and data are protected from unauthorized modification or deletion either - by malicious action or computer error. - - - **Non-repudiation** - - - Degree to which actions or events can be proven to have taken place so that - the events or actions cannot be repudiated later. - - - **Accountability** - - - Degree to which the actions of an entity can be traced uniquely to the entity. - - - **Authenticity** - - - Degree to which the identity of a subject or resource can be proved to be - the one claimed. - - - **Resistance** - - - Degree to which the product or system sustains operations while under attack - from a malicious actor.' - identifier: https://w3id.org/everse/i/dimensions/security - name: Security - source: - name: ISO/IEC 25010 standard - url: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 -- abbreviation: sustainability - description: The capacity of the software to endure. In other words, sustainability - means that the software will continue to be available in the future, on new - platforms, meeting new needs. - identifier: https://w3id.org/everse/i/dimensions/sustainability - name: Sustainability - source: - name: Defining Software Sustainability - url: https://danielskatzblog.wordpress.com/2016/09/13/defining-software-sustainability/ +[] diff --git a/pages/research_software_stories/alpaka_research_software_story.md b/pages/research_software_stories/alpaka_research_software_story.md new file mode 100644 index 00000000..4138a151 --- /dev/null +++ b/pages/research_software_stories/alpaka_research_software_story.md @@ -0,0 +1,208 @@ +--- +title: "Research Software Story - alpaka" +search_exclude: false +description: "alpaka is a header-only C++ template library that enables writing platform and performance portable applications. It can use CPUs with sequential and thread parallel code, GPUs via multiple programming paradigms and also FPGAs." +contributors: ["Guido Juckeland", "Srobona Ghosh", "René Widera", "Simeon Ehrig"] +page_id: alpaka +type: research_software_story +--- + +## The Problem +### Achieving performance portability in an increasingly heterogeneous HPC landscape + +alpaka is a header-only C++ template library that enables writing [platform and performance portable applications][ALPAKA_GITHUB]. +It can use CPUs with sequential and thread parallel code, GPUs via multiple programming paradigms. +The library addresses the fundamental challenge facing HPC developers: how to write high-performance code once and run it efficiently across diverse hardware platforms without maintaining separate implementations for each architecture. + +Traditional approaches required separate code paths, within the user application, for NVIDIA GPUs ([CUDA][CUDA]), [AMD GPUs][HIP] ([HIP/ROCm][HIP]), [Intel GPUs][SYCL] ([oneAPI/SYCL][SYCL]), and multicore x86/ARM/RISCV CPUs ([OpenMP][OPENMP]). +This multiplication of code creates enormous maintenance burdens and makes verification difficult. +alpaka solves this by providing a single abstraction layer where developers write algorithms once using portable interfaces, then compile to native code for different hardware backends. + +## User Community +### Joint development between HZDR and CERN serving the HPC community + +alpaka is jointly developed at the [Helmholtz-Zentrum Dresden-Rossendorf (HZDR)][HZDR] and [CERN][CERN] (CMS experiment). +The development team combines computer scientists and physicists, with work mainly driven through PhD and master's thesis projects alongside requirements from CERN's experimental collaborations. + +**Development team composition:** +- HZDR and CMS are focused on core library architecture and performance optimization +- CMS collaboration developers at CERN driving requirements for high-energy physics data processing +- HZDR taking care of plasma physics simulation requirements +- HZDR is developing features based on external user requirements from [DLR][DLR] and [HZB][HZB] +- HZDR is developing the testing strategies and infrastructure to guarantee the code quality +- PhD and master's students contributing focused improvements and new features + +**User base characteristics:** +- Advanced [C++][LANGUAGE_CPP] programmers working in HPC environments +- Researchers needing codes to work across different computing centers with varying hardware +- CMS experiment and other scientific collaborations requiring performance portability +- Users comfortable with parallel programming concepts and template-heavy C++ code + +The community maintains connection through [online videos](https://m.youtube.com/playlist?list=PLVyQXsMxRYdEoahVQAqf9_rewGj3VkXb4) ([alternative](https://m.youtube.com/playlist?list=PLUGnsLpYzQZsEqvH675ghq3ibACjFIKQh)) and [onboarding documents][ALPAKA_DOCS], a [Mattermost][TOOL_MATTERMOST] team with core users, and personnel exchange visits between institutions. + +## Technical Aspects +### Header-only C++ template library for compile-time code generation + +alpaka is classified as Tier 3 Research Software Infrastructure (Services included), reflecting its critical enabling role for other scientific applications. + +**Technical specifications:** +- **Language:** Modern [C++20][LANGUAGE_CPP20] for expressive template metaprogramming +- **Codebase size:** Approximately 45k lines of code (30k in core library headers) and 10k lines of comments +- **Architecture:** Header-only library that doesn't "run" but translates at compile time +- **Compilation approach:** Compiler processes templates to generate hardware-specific code ({% tool "cuda" %}, [HIP][HIP]/[ROCm][ROCm], [OpenMP][OPENMP], etc.) +- **Performance:** Zero runtime overhead compared to hand-written platform-specific code + +When developers write alpaka-based algorithms and compile with a specific backend selected, the compiler produces native code for that platform. +Compiling the same source with different backends produces different optimized implementations from a single codebase. + +### Libraries and Systems + +alpaka's dependencies vary based on the selected compilation backend: + +- **{% tool "cuda" %}:** Required when compiling for NVIDIA GPUs +- **[HIP][HIP]/[ROCm][ROCm]:** Required when targeting AMD GPUs +- **[OneAPI SYCL][SYCL]:** Required for Intel GPUs or optionally CPUs +- **[OpenMP][OPENMP]:** Used for thread-parallel CPU execution +- **[TBB (Threading Building Blocks)][TBB]:** Alternative for task-based CPU parallelism + +This backend architecture means deploying alpaka-based code requires only the specific toolchain relevant to the target hardware, keeping deployment practical despite broad platform support. + +## Software Quality Practices +### Comprehensive testing across thousands of hardware configurations + +alpaka follows disciplined development practices essential for a library supporting such diverse platforms: + +- **Version control:** {% tool "git" %} with the main repository on [GitHub][ALPAKA_GITHUB] +- **Contribution guidelines:** Detailed guidelines in [CONTRIBUTING.md][ALPAKA_CONTRIBUTING] maintain consistency across contributors +- **Code review:** Mandatory peer review before merging changes +- **Coding standards:** Comprehensive [guidelines documented][ALPAKA_STYLE] for maintaining code quality + +The most remarkable quality practice is the extensive continuous integration infrastructure testing every change across thousands of configurations. +The CI system routes code from {% tool "github" %} through [GitLab.com][GITLAB] to HZDR's local GitLab CI infrastructure with access to diverse hardware accelerators. +Each change triggers: + +- Static code quality checks through linting +- Compilation testing across all supported C++ compilers, hardware backends, and configurations +- Test suite execution verifying correctness on each platform + +Results push back to GitHub pull requests, providing immediate feedback about cross-platform compatibility. +The code also integrates into multiple HPC compiler vendor and hardware manufacturer CI/CD test environments. + +## Developer Community +### Individualized onboarding for template metaprogramming expertise + +Onboarding new alpaka developers requires attention to the specialized C++ template metaprogramming knowledge needed to work effectively with the library. +The process is highly individualized, tailored to each contributor's background and the specific areas where they'll work. + +**Resources for developers:** +- [Online videos](https://m.youtube.com/playlist?list=PLVyQXsMxRYdEoahVQAqf9_rewGj3VkXb4) ([alternative](https://m.youtube.com/playlist?list=PLUGnsLpYzQZsEqvH675ghq3ibACjFIKQh)) introducing alpaka's architecture and design philosophy +- [Written documentation][ALPAKA_DOCS] explaining the template machinery +- [Mattermost][TOOL_MATTERMOST] team for real-time support from experienced developers +- Personnel exchange visits for intensive knowledge transfer through pair programming + +**Typical user journey:** +New users typically start by adapting existing code from one platform (e.g., {% tool "cuda" %}) to use alpaka's portable interfaces. +They begin by compiling only for familiar backends to verify correctness, then experiment with other platforms while comparing performance and debugging platform-specific issues. + +## Tools +### Performance profiling across diverse accelerator platforms + +alpaka works well with standard profiling tools for various platforms: + +- **[NVIDIA Nsight][NVIDIA_NSIGHT]** for NVIDIA GPU performance analysis +- **[AMD Omniperf][AMD_OMNIPERF]** for AMD GPU optimization +- **[Score-P][SCOREP]** for general parallel performance analysis + +Profiling can be challenging due to the highly asynchronous nature of GPU execution and complex control flow from template-based abstractions. +The development team uses these tools to verify memory access patterns are efficient and that kernel launches don't introduce unnecessary overhead. + +Like PIConGPU, alpaka has been incorporated into compiler vendor and hardware manufacturer testing environments, where it serves as a stress test for C++ template implementations and optimization capabilities. + +## FAIR & Open +### Open development supporting collaborative cross-institution research + +alpaka adheres to the [FAIR principles for research software][FAIR_PRINCIPLES]: + +* **Findable**: The code is openly available on [GitHub][ALPAKA_GITHUB] with clear versioning, and releases are archived with assigned DOIs for academic referencing. + +* **Accessible**: Core licensed under [MPLv2 (Mozilla Public License v2.0)][LICENSE_MPL2], examples under [ISC (Internet Systems Consortium)][LICENSE_ISC] allowing incorporation into projects with different licensing requirements; documentation under [CC-BY 4.0][LICENSE_CCBY]. + +* **Interoperable**: Designed to work seamlessly with standard HPC frameworks and supports multiple hardware backends ({% tool "cuda" %}, [HIP][HIP], [OpenMP][OPENMP], [SYCL][SYCL]), enabling integration across diverse computing environments. + +* **Reusable**: alpaka provides well-documented, tested components with comprehensive [coding guidelines][ALPAKA_STYLE] and clear [contribution process][ALPAKA_CONTRIBUTING], enabling reuse and easy adaptation across multiple research projects. + +Development happens openly with features, architectural decisions, and bug reports discussed in public [GitHub Issues][ALPAKA_ISSUES]. +The MPLv2 licensing ensures the library remains free and open while accommodating use by large experimental collaborations with complex software licensing requirements. + +## Documentation +### Multi-level resources for diverse technical audiences + +alpaka documentation is organized to serve different user groups: + +- **Conceptual overviews:** Explaining the programming model and abstraction design +- **Installation guides:** Configuration for different backends and integration into projects +- **Tutorials:** Demonstrating common usage patterns through concrete examples +- **Developer documentation:** Architecture explanations and contribution guidance +- **API reference:** Technical specifications for library interfaces + +The primary documentation lives at using [Read the Docs][READTHEDOCS] for versioned access. +Documentation is mainly written and maintained by the core development team, with contributions often arriving as part of pull requests introducing new features. + +## Sustainability +### Institutional funding and community governance ensure long-term evolution + +alpaka's sustainability model supports evolution over multi-decade timescales: + +**Funding and staffing:** +- Part of Helmholtz base-funded research activities at HZDR +- Permanently funded RSE as maintainer, ensuring continuity +- Coordination between HZDR and CERN ensures alignment with both general HPC and experimental collaboration needs + +**Governance:** +- Project builds on well-established FOSS community practices +- Guidance from experienced researchers and RSEs maintains coherent architecture +- Thesis-driven development provides fresh contributions while experienced maintainers preserve long-term vision + +**Recognition:** +- Author and contributor lists maintained in the software repository +- Software authors for specific scientific applications listed as co-authors on academic publications +- Citeable DOI enables proper acknowledgment in publications + +The combination of institutional support, dual-institution governance, and established community practices positions alpaka well for continued evolution as hardware platforms and programming models advance. + +## References + +- alpaka GitHub Repository: +- Main publication: Matthes, A., et al. (2016). Tuning and optimization for a variety of many-core architectures without changing a single line of implementation code using the alpaka library. +- alpaka Documentation: +- Coding Guidelines: +- Software Citation: [DOI 10.5281/zenodo.595380](https://doi.org/10.5281/zenodo.595380) + + +[HZDR]: https://www.hzdr.de/ +[CERN]: https://home.cern/ +[DLR]: https://www.dlr.de/ +[HZB]: https://www.helmholtz-berlin.de/ +[LANGUAGE_CPP]: https://en.cppreference.com/w/cpp +[LANGUAGE_CPP20]: https://en.cppreference.com/w/cpp/20 +[TOOL_MATTERMOST]: https://mattermost.com/ +[CUDA]: https://developer.nvidia.com/cuda-toolkit +[HIP]: https://rocm.docs.amd.com/projects/HIP/en/latest/ +[SYCL]: https://www.khronos.org/sycl/ +[OPENMP]: https://www.openmp.org/ +[TBB]: https://www.intel.com/content/www/us/en/developer/tools/oneapi/onetbb.html +[ALPAKA_GITHUB]: https://github.com/alpaka-group/alpaka +[ALPAKA_CONTRIBUTING]: https://github.com/alpaka-group/alpaka/blob/develop/CONTRIBUTING.md +[ALPAKA_STYLE]: https://alpaka.readthedocs.io/en/latest/dev/style.html +[ALPAKA_ISSUES]: https://github.com/alpaka-group/alpaka/issues +[ALPAKA_DOCS]: https://alpaka.readthedocs.io +[GITLAB]: https://gitlab.com +[NVIDIA_NSIGHT]: https://developer.nvidia.com/nsight-systems +[AMD_OMNIPERF]: https://rocm.docs.amd.com/projects/omniperf/en/latest/ +[SCOREP]: https://www.vi-hps.org/projects/score-p/ +[FAIR_PRINCIPLES]: https://www.nature.com/articles/s41597-022-01710-x +[LICENSE_MPL2]: https://www.mozilla.org/en-US/MPL/2.0/ +[LICENSE_ISC]: https://opensource.org/license/isc-license-txt +[LICENSE_CCBY]: https://creativecommons.org/licenses/by/4.0/ +[READTHEDOCS]: https://readthedocs.org/ +[ROCm]: https://rocm.docs.amd.com/en/latest/ \ No newline at end of file diff --git a/pages/research_software_stories/picongpu_research_software_story.md b/pages/research_software_stories/picongpu_research_software_story.md new file mode 100644 index 00000000..2886b294 --- /dev/null +++ b/pages/research_software_stories/picongpu_research_software_story.md @@ -0,0 +1,190 @@ +--- +title: "Research Software Story - PIConGPU" +search_exclude: false +description: "PIConGPU is used to simulate nonlinear plasma physics, from laser plasma accelerators to astrophysics research." +contributors: ["Guido Juckeland", "Srobona Ghosh", "René Widera", "Richard Pausch"] +page_id: picongpu +type: research_software_story +--- + +## The Problem +### Simulating extreme laser-plasma physics for next-generation accelerators + +PIConGPU is a [particle-in-cell code][PICONGPU_GITHUB] used to simulate [nonlinear plasma physics][PLASMA_PHYSICS]. +It is primarily used for [laser plasma acceleration][LASER_PLASMA_ACCEL], such as laser wakefield and target normal sheath acceleration, but it is also frequently applied to astrophysical scenarios, such as magnetic reconnection and shear surface instabilities in interstellar jets. +These extreme physical conditions require a fully relativistic approach and three-dimensional (3D) modeling of spatial coordinates and velocity space, which presents a substantial computational challenge. +This software provides accurate, high-performance simulations that can run on modern [supercomputing architectures][HPC_ARCHS], supporting experimental design and theoretical understanding in plasma physics research. + +## User Community +### Collaborative development driven by physics and computer science experts + +PIConGPU is primarily developed at the [Helmholtz-Zentrum Dresden-Rossendorf (HZDR)][HZDR], where the team combines expertise from computer science and physics. +The development of physics capabilities is primarily driven by students as part of their Ph.D. or master's thesis work. This creates a dynamic environment in which early-career researchers can contribute to the project while advancing their own research goals under the supervision of a senior computational physicist. +In parallel, RSEs (research software engineers) mainly drive workflow design, domain-specific coupling between the computer science domain and physics simulations, and overall code maintenance. + +The development team consists of: +- A few computer scientists focused on software architecture and performance +- A larger group of physicists driving scientific requirements +- PhD and master's students as primary contributors of new features + +Users of PIConGPU are mainly researchers simulating laser-driven particle acceleration. +They tend to be advanced [C++][LANGUAGE_CPP] users with strong computational backgrounds, capable of working within complex HPC environments and handling the sophisticated build requirements of the software. + +The community maintains connection through [online videos and comprehensive onboarding documents][PICONGPU_DOCS], a [Mattermost][TOOL_MATTERMOST] team with core users, and personnel exchange visits that facilitate knowledge transfer between institutions. + +## Technical Aspects +### Modern C++ with extensive compilation infrastructure + +PIConGPU is classified as Tier 3 Research Software Infrastructure (Services included), reflecting its maturity and the comprehensive support provided to users. + +**Technical specifications:** +- **Language:** Modern [C++20][LANGUAGE_CPP20] for the source code, with [Python][LANGUAGE_PYTHON] bindings available for easier interaction +- **Codebase size:** Approximately 80k lines of code (including the PMacc library) plus roughly 55k lines of comments and documentation +- **Build system:** {% tool "cmake" %} for building and installation +- **Deployment:** Can ideally install on local machines if prerequisites are satisfied, but primarily targets HPC systems +- **Compilation characteristics:** Long compile times (~3+ minutes) for each setup due to heavy use of C++ templates for performance optimization +- **Parameter handling:** Simulation parameters are transported via {% tool "cmake" %} into the code, requiring recompilation when input parameters change + +This compilation-time parameter binding allows aggressive compiler optimizations but creates a different workflow than traditional runtime configuration approaches. + +### Libraries and Systems + +PIConGPU builds on several key dependencies: + +- **[alpaka][ALPAKA]**: Core abstraction library enabling portability across different accelerators +- **{% tool "cmake" %}:** Build configuration and management +- **[MPI][MPI]:** Parallel execution across multiple nodes +- **[Boost][Boost]:** Essential C++ utilities and data structures +- **[OpenPMD-api][OPENPMD]:** HPC IO abstraction library for parallel [ADIOS2][ADIOS2] or [HDF5][HDF5] + +The focused dependency set reflects a deliberate strategy of relying on well-established, widely-available libraries rather than accumulating numerous smaller dependencies. + +## Software Quality Practices +### Rigorous testing across thousands of hardware configurations + +PIConGPU follows disciplined software engineering practices with comprehensive version control and contribution guidelines: + +- **Version control:** {% tool "git" %}, with the main repository hosted on [GitHub][PICONGPU_GITHUB] +- **Contribution process:** Guidelines documented in [CONTRIBUTING.md][PICONGPU_CONTRIBUTING] within the repository +- **Code review:** Changes reviewed before integration to maintain quality + +The most distinctive aspect of PIConGPU's quality infrastructure is its extensive continuous integration setup. +The CI workflow moves code from {% tool "github" %} via [GitLab.com][GITLAB] to HZDR's local GitLab CI infrastructure, then pushes all pipeline results back to GitHub pull requests. +This complex pipeline: + +- Checks static code quality through linting and code style enforcement +- Compiles test cases for all supported combinations of hardware architectures, accelerators (GPUs), and libraries +- Generates hundreds of CI jobs per change +- Runs tests and validates output against expected results + +The code also integrates with multiple HPC compiler and hardware vendor CI/CD test environments, serving as a real-world stress test for their tools. + +## Developer Community +### Structured support for physicists learning computational methods + +The PIConGPU project provides multiple resources to help newcomers: + +- [Online videos and comprehensive onboarding documents][PICONGPU_DOCS] introducing the software's purpose and architecture +- A [Mattermost][TOOL_MATTERMOST] team where developers and users can ask questions and share solutions +- Personnel exchange visits allowing researchers to work directly with core developers + +The typical user journey starts with learning to run existing simulation setups and modify parameters. +As users gain experience, they progress to adapting simulation geometries and incorporating new initial conditions. +Advanced users eventually contribute new physical models or extend the code's capabilities for their specific research needs. + +## Tools +### Performance profiling across diverse accelerator architectures + +PIConGPU works well with industry-standard performance profiling tools including: + +- **[NVIDIA Nsight][NVIDIA_NSIGHT]** for NVIDIA GPUs +- **[AMD Omniperf][AMD_OMNIPERF]** for AMD GPUs +- **[Score-P][SCOREP]** for general parallel performance analysis + +The highly asynchronous nature of particle-in-cell algorithms makes profiling challenging, as GPU operations may overlap with CPU work and communication in complex ways. +Despite these challenges, detailed profiling helps developers identify bottlenecks and optimize critical code paths. + +## FAIR & Open +### Transparent development with strong licensing and citability + +PIConGPU adheres to the [FAIR principles for research software][FAIR_PRINCIPLES]: + +* **Findable**: The code is openly available on [GitHub][PICONGPU_GITHUB] with clear versioning, and major releases are archived with assigned DOIs for academic referencing. + +* **Accessible**: Licensed under [GPLv3+][LICENSE_GPL3] for the main code, [LGPLv3+][LICENSE_LGPL3] for libraries, and [CC-BY 4.0][LICENSE_CCBY] for documentation, facilitating open access and wide adoption. + +* **Interoperable**: Designed to work with standard HPC frameworks and supports multiple accelerator backends through [alpaka][ALPAKA], enabling integration across diverse computing environments. + +* **Reusable**: PIConGPU provides well-documented, tested components with clear [contribution guidelines][PICONGPU_CONTRIBUTING] and [commit rules][PICONGPU_COMMIT_RULES], enabling reuse and easy adaptation across multiple research projects. + +Development happens openly, with discussions about features, bugs, and design decisions occurring in public [GitHub Issues][PICONGPU_ISSUES]. The GPL licensing ensures that improvements benefit the entire community rather than being captured in proprietary forks. + +## Documentation +### Multi-level resources serving diverse user needs + +PIConGPU provides documentation organized for different audiences: + +- **User documentation:** Installation guides, tutorials, and usage examples +- **Developer documentation:** Code structure explanations and contribution guidelines +- **Maintainer documentation:** Release processes and long-term decisions on code structure + +The primary documentation lives at , using [Read the Docs][READTHEDOCS] for versioned, searchable access. +Documentation is mainly written and maintained by the core development team, with contributions often arriving as part of pull requests when new features are added. + +## Sustainability +### Institutional commitment ensures long-term viability + +PIConGPU benefits from stable institutional support: + +**Funding model:** +- Part of Helmholtz base-funded research activities at HZDR +- Permanently funded RSEs serving as maintainer, ensuring continuity beyond individual researchers +- Further RSEs funded via European project for HPC and plasma research + +**Governance:** +- Project builds on well-established FOSS community practices +- Development guided by experienced researchers and RSEs who maintain overall architecture +- Benefits from thesis-driven development while maintaining coherent long-term vision + +**Recognition:** +- Author and contributor lists maintained in the software repository +- Software authors for specific scientific use cases listed as authors on academic publications + +The combination of permanent funding, experienced maintainers, and established community practices positions PIConGPU well for long-term sustainability as computing architectures and research needs evolve. + +## References + +- PIConGPU GitHub Repository: +- Main publication: Bussmann, M., et al. (2013). Radiative signatures of the relativistic Kelvin-Helmholtz instability. +- PIConGPU Documentation: +- Software Citation: [DOI 10.5281/zenodo.591746](https://doi.org/10.5281/zenodo.591746) + + +[HZDR]: https://www.hzdr.de/ +[LANGUAGE_CPP]: https://en.cppreference.com/w/cpp +[LANGUAGE_CPP20]: https://en.cppreference.com/w/cpp/20 +[LANGUAGE_PYTHON]: https://www.python.org/ +[TOOL_MATTERMOST]: https://mattermost.com/ +[ALPAKA]: https://alpaka.readthedocs.io/ +[OPENPMD]: https://openpmd-api.readthedocs.io/ +[ADIOS2]: https://adios2.readthedocs.io/ +[HDF5]: https://www.hdfgroup.org/solutions/hdf5/ +[PICONGPU_GITHUB]: https://github.com/ComputationalRadiationPhysics/picongpu +[PICONGPU_CONTRIBUTING]: https://github.com/ComputationalRadiationPhysics/picongpu/blob/dev/CONTRIBUTING.md +[PICONGPU_COMMIT_RULES]: https://github.com/ComputationalRadiationPhysics/picongpu/blob/dev/docs/COMMIT.md +[PICONGPU_ISSUES]: https://github.com/ComputationalRadiationPhysics/picongpu/issues +[PICONGPU_DOCS]: https://picongpu.readthedocs.io +[GITLAB]: https://gitlab.com +[NVIDIA_NSIGHT]: https://developer.nvidia.com/nsight-systems +[AMD_OMNIPERF]: https://rocm.docs.amd.com/projects/omniperf/en/latest/ +[SCOREP]: https://www.vi-hps.org/projects/score-p/ +[FAIR_PRINCIPLES]: https://www.nature.com/articles/s41597-022-01710-x +[LICENSE_GPL3]: https://www.gnu.org/licenses/gpl-3.0.en.html +[LICENSE_LGPL3]: https://www.gnu.org/licenses/lgpl-3.0.en.html +[LICENSE_CCBY]: https://creativecommons.org/licenses/by/4.0/ +[READTHEDOCS]: https://readthedocs.org/ +[PLASMA_PHYSICS]: https://en.wikipedia.org/wiki/Plasma_(physics) +[LASER_PLASMA_ACCEL]: https://en.wikipedia.org/wiki/Laser-plasma_accelerator +[HPC_ARCHS]: https://www.top500.org/ +[MPI]: https://www.open-mpi.org/doc/ +[Boost]: https://www.boost.org/libraries/latest/grid/ \ No newline at end of file