[Ecosystem] PINA

[dario-coscia]

Contact emails

pina.mathlab@gmail.com, dcoscia@sissa.it, gcanali@sissa.it, folivo@sissa.it, ndemo@sissa.it

Project summary

PINA is an open-source library designed to simplify and accelerate the development of Scientific Machine Learning solutions.

Project description

PINA is an open-source library designed to simplify and accelerate the development of Scientific Machine Learning (SciML) solutions. It provides a consistent and modular framework for building and experimenting with models such as Neural Networks, Physics-Informed Neural Networks (PINNs), Neural Operators and more. Designed with composable abstractions, PINA allows researchers to plug in, replace, or extend components effortlessly, making experimentation both fast and flexible. It scales seamlessly across devices, delivering performance close to hand-crafted implementations while remaining easy to use.

Are there any other projects in the PyTorch Ecosystem similar to yours? If, yes, what are they?

The closest package to ours is simulAI, which provides contributions to the SciML ecosystem, particularly with implementations of vanilla PINNs and DeepONet. Unlike simulAI, PINA is designed to be truly versatile, supporting a wide range of SciML tasks; from molecular property prediction to solving complex PDEs, for instance. It also goes beyond the basics, incorporating not only standard approaches but also many of their state-of-the-art variants that address limitations of the original methods. Finally, PINA is an active project, with continuous updates and regular maintenance to ensure researchers can rely on the latest tools and techniques.

Project repo URL

https://github.com/mathLab/PINA

Additional repos in scope of the application

No response

Project license

The MIT License (MIT)

GitHub handles of the project maintainer(s)

@GiovanniCanali, @dario-coscia, @ndem0, @AleDinve, @annaivagnes, @FilippoOlivo, @guglielmopadula, @fpichi

Is there a corporate or academic entity backing this project? If so, please provide the name and URL of the entity.

SISSA mathLab, Mathematics Area, SISSA (Scuola Internazionale Superiore di Studi Avanzati), Trieste, Italy. URL: https://mathlab.sissa.it/pina

Website URL

https://github.com/mathLab/PINA

Documentation

Our documentation is available at: https://mathlab.github.io/PINA/

We have a list of getting started tutorials: https://mathlab.github.io/PINA/_tutorial.html#getting-started-with-pina, but also more advanced tutorials.

How do you build and test the project today (continuous integration)? Please describe.

The repository includes various continuous integration pipelines through GitHub workflows. Below we highlight the main ones, while the full list is available here:

• Automated Tests: We run static code analysis and documentation build tests.
• Coverage: We verify code quality and monitor test coverage through automated checks.
• Automated Releases: We publish a release on PyPI once per month, which also automatically updates the documentation.

Version of PyTorch

The repository works (and has been tested) with PyTorch versions ≥ 2.0, while maintaining backward compatibility with earlier versions. Continuous integration is performed using the latest stable release of PyTorch.

Components of PyTorch

We use different components of PyTorch across the repository:

• torch.nn.Module (with optional buffers) in pina.model and pina.model.block for building state-of-the-art SciML architectures.
• torch.autograd in our differential operators module (pina.operator).
• torch.utils.data for the data loading pipeline.
• Linear algebra routines and standard PyTorch operations throughout the codebase.

How long do you expect to maintain the project?

Indefinitely

Additional information

Our software has been accepted to the JOSS journal.
Link to the paper: https://joss.theoj.org/papers/10.21105/joss.05352

[lantiga]

Thank you for the submission @dario-coscia! Super interesting project, we'll get back shortly with structured feedback.

[lantiga]

Thank you again for the submission @dario-coscia, awesome contribution.
The project ticks all boxes, only the activity is borderline (off by a few units as mentioned below), but given the relevance and quality of the project we should proceed to the vote.

Functional Requirements:

✅ 1. PyTorch Support: Project must demonstrate benefit to the pytorch community and be validated with the latest versions of PyTorch.
✅ 2. Working CI: Projects must have a demonstrable working CI workflow for all declared architectures
✅ 3. Governance: Projects must have documented technical governance defined and implemented and it must be represented in their Github or Gitlab repository. Example: Review the LF’s Minimum Viable Governance framework.
✅ 4. User experience: The value proposition should be made clear for the project and documented in the README of the project repository.
✅ 5. Quick start: Project should have a working and demonstrable quick start.
✅ 6. Documentation: Projects must have clear and comprehensive documentation.
✅ 7. Permissive licensing: Users must be able to utilize ecosystem projects without licensing concerns. e.g. BSD-3, Apache-2 and MIT licenses
✅ 8. Functional Testing: Users should have developed tests submitted as a part of their project, and be confident that the project will work well with the latest releases of PyTorch.
✅ 9. Packages: Projects need to have support for binary installation options (pip/Conda).
✅ 10. Ongoing maintenance: Project maintainers must be committed to supporting and maintaining their projects for the next 12 months at a minimum. Projects must commit to updating their projects to the latest two releases of PyTorch (e.g. versions 2.6, 2.5.1).

Measurable Requirements:

✅ 1. Core Maintainers: The project must have a minimum of 2 core maintainers
✅ 2. Contributors: The project should have a minimum of 5 total contributors active in the last 90 days.
🟡 3. Commits: The project must have 30 commits in the last 90 days. This is off by like 15 days: it shouldn't be a deal breaker.
✅ 4. Stars: The project must have a minimum of 200 stars on github

Github Layout Requirements:

✅ 1. LICENSE.md at the root of the repository specifying the terms and conditions for using, distributing, and modifying the software. In addition, you should provide information on the license of any third-party code included in the project.
✅ 2. README.md welcomes new community members to the project and explains why the project is useful and how to get started. Should include information about release methodology, cadence, and criteria in the README.
✅ 3. CONTRIBUTING.md explains how to contribute to the project. The file explains the types of contributions needed and how the development process works.
✅ 4. CODEOWNERS that define individuals or teams responsible for code in a repository; document current project owners and Retired committers.
✅ 5. CODE_OF_CONDUCT.md sets the ground rules for participants’ behavior and helps facilitate a friendly, welcoming environment. By default, projects should leverage the [Linux]([https://lfprojects.org/policies/code-of-conduct/) [Foundation](https://lfprojects.org/policies/code-of-conduct/) [Code](https://lfprojects.org/policies/code-of-conduct/) of [Conduct](https://lfprojects.org/policies/code-of-conduct/) unless](https://lfprojects.org/policies/code-of-conduct/)%C2%A0%5B%5BFoundation%5D(https://lfprojects.org/policies/code-of-conduct/)%5D(https://lfprojects.org/policies/code-of-conduct/)%C2%A0%5B%5BCode%5D(https://lfprojects.org/policies/code-of-conduct/)%5D(https://lfprojects.org/policies/code-%5Bof%5D(https://lfprojects.org/policies/code-of-conduct/)-conduct/)%C2%A0%5Bof%5D(https://lfprojects.org/policies/code-of-conduct/)%C2%A0%5B%5BConduct%5D(https://lfprojects.org/policies/code-of-conduct/)%5D(https://lfprojects.org/policies/code-of-conduct/)%C2%A0unless) an alternate Code of Conduct is approved prior.

[dario-coscia]

Hi @lantiga, thank you for the kind feedback — we really appreciate it!

Also, thanks for your comments on the commits. We usually keep pull requests to a single commit to keep the history tidy. Most of the development occurs in the dev branch, and we only merge into master for stable releases; therefore, there are fewer commits in the master branch.

We'll wait for the vote — thanks again for your time and support 😊