Feel++ Package

1. Description

Feel is an open-source, high-performance C framework for solving complex PDE and ODE-based mathematical models using advanced Galerkin methods (finite element, discontinuous Galerkin, and spectral methods) and efficient reduced-order modeling (ROM) techniques, including Reduced Basis (RB), Proper Orthogonal Decomposition (POD), and Empirical Interpolation Methods (EIM). It features specialized application toolboxes (CFD, CSM, FSI, thermoelectric, Maxwell), modern parallel computing with seamless Python integration (Pybind11), and extensive DevOps support (CI/CD, benchmarking, and containers). Feel++ is used in academia and industry for multiphysics simulations, inverse problems, uncertainty quantification, data assimilation, and machine learning applications.

2. Packaging

Software should be packaged (preferably using Spack or Guix package formats). They should be published in public (community controlled) package repositories (Guix-science, etc.).

Available packages:

  • Debian

  • Ubuntu

  • Fedora

  • Spack

  • GUIX-HPC

3. Minimal Validation Tests

Software should include minimal validation tests triggered through automated mechanism such as Guix. These tests should be automatic functional tests that do not require specific hardware.

  • Unit tests exist

  • CI exists

  • CI runs regularly (each new release)

  • CI runs regularly (each commit)

4. Public Repository

A public repository, must be available for at least the development version of the software, allowing for pull requests to be submitted.

  • Publicly available source repository

  • Supports contribution via pull requests

Repository: github.com/feelpp/feelpp

5. Clearly-identified license

Sources should be published under a clearly-identified free software license (preferably with REUSE)

  • License clearly stated

  • FLOSS license (FSF/OSI conformant)

  • SPDX is used

  • REUSE is used

    • OSS:: LGPL v*

    • OSS:: GPL v*

6. Minimal Documentation

Basic documentation should be publicly available to facilitate user understanding and usage of the software.

7. Open Public Discussion Channel

An open, public discussion channel must be provided that is easily accessible to all potential users. The chosen platform must not require special permissions or memberships that could limit user participation.

8. Metadata

Each repository should include metadata easing integration and publicity on a software list.

  • The following metadata is available:

    • Software name: ✅

    • Description: ✅

    • License: ✅

    • Documentation URL: ✅

    • Discussion channel URL: ✅

    • Package repositories URLs: ✅

    • Repository URL: ✅

    • Autoevaluation using the list of criteria stated here: ✅

  • Uses codemeta format

9. API Compatibility Information

Each repository should include information enabling downstream users to know which versions they can use

  • API changes documented

  • Semantic Versioning used

  • Clear release policy

10. Minimal Performance Tests

Software should include a minimal set of performance tests divided in three categories: single node without specific hardware, single node with specific hardware, multi-nodes. These tests should be automated as much as possible.

  • Tests exist

  • Scripts to automate tests on supercomputers

  • Scripts/tools easing portability to new hardware