Open-source deep-learning framework for building, training, and fine-tuning deep learning models using state-of-the-art Physics-ML methods
PhysicsNeMo is an open-source PyTorch framework for creating, training, and fine-tuning machine-learning models for physics, scientific computing, and engineering. Researchers and engineers use its reusable components and training recipes for applications such as aerodynamics, weather forecasting, structural mechanics, geophysics, and thermal design. The catalogue entries provide rules and skills for working with PhysicsNeMo projects.
Cursor rule Cursor ✓ vendor
Reusable layers and building blocks should be placed in physicsnemo/nn, not physicsnemo/models. Examples include FullyConnected, attention layers, and UNetBlock.
Cursor rule Cursor ✓ vendor
Complete models composed of multiple layers should be placed in physicsnemo/models, not physicsnemo/nn. These are domain-specific or modality-specific models.
Cursor rule Cursor ✓ vendor
All model and layer classes must inherit from physicsnemo.Module (not torch.nn.Module directly) to ensure proper serialization, versioning, and registry functionality.
Cursor rule Cursor ✓ vendor
New model classes should start in physicsnemo/experimental/nn or physicsnemo/experimental/models during development, where backward compatibility is not guaranteed.
Cursor rule Cursor ✓ vendor
Model classes being deprecated must include deprecation warnings in both docstring and runtime, explaining why and what users should use instead, for at least 1 release cycle.
Cursor rule Cursor ✓ vendor
After at least 1 release cycle in pre-deprecation stage with warnings, deprecated model classes can be deleted from the codebase.
Cursor rule Cursor ✓ vendor
Every model/layer requires comprehensive docstrings following NumPy style with Sphinx RST formatting, including all sub-rules MOD-003b through MOD-003k.
Cursor rule Cursor ✓ vendor
Model and method docstrings must be prefixed with r""" (raw string with triple double quotes) for proper LaTeX rendering in Sphinx documentation.
Cursor rule Cursor ✓ vendor
Class docstrings must contain three mandatory sections - Parameters, Forward, and Outputs. Optional sections include Notes, Examples, ..important::, and ..code-block::.
Cursor rule Cursor ✓ vendor
All methods must have docstrings with at least Parameters and Returns sections. Optional sections include Notes, Examples, ..important::, and ..code-block::.
Cursor rule Cursor ✓ vendor
All tensor shapes in docstrings must use LaTeX math notation like :math:(B, C, H, W) for proper rendering in Sphinx documentation.
Cursor rule Cursor ✓ vendor
Callback function parameters must include a ..code-block:: specification showing the required signature and return type, placed outside Parameters/Forward/Outputs sections.
Cursor rule Cursor ✓ vendor
Inline code in docstrings must be formatted with double backticks code, not single backticks, as single backticks don't render properly in Sphinx.
Cursor rule Cursor ✓ vendor
All parameters must be documented with their type and default values on a single line following NumPy docstring style format.
Cursor rule Cursor ✓ vendor
Docstrings should use Sphinx cross-references (:class:, :func:, :meth:) to link to other code elements and external resources for better documentation connectivity.
Cursor rule Cursor ✓ vendor
Docstrings should include an Examples section with executable code demonstrating usage, as these are automatically tested by CI for correctness.
Cursor rule Cursor ✓ vendor
Complex tensor operations should include high-level semantic comments explaining what blocks of code do, plus inline shape comments for chained operations using symbols consistent with docstrings.
Cursor rule Cursor ✓ vendor
All utility functions specific to a model must be in the same module file as the model itself, not in separate utility files, to maintain self-contained modules.
Cursor rule Cursor ✓ vendor
All forward and public methods must validate tensor shapes at the beginning, wrapped in torch.compiler.iscompiling() guard, with standardized error messages.
Cursor rule Cursor ✓ vendor
All tensor arguments in model methods must have jaxtyping type annotations with shape specifications (e.g. Float[torch.Tensor, "b c h w"]) for runtime-checkable shape information.
Cursor rule Cursor ✓ vendor
Cannot add new required parameters to production model init or public methods without default values, as this breaks backward compatibility with existing code and checkpoints.
Cursor rule Cursor ✓ vendor
Cannot remove or rename parameters in production models without implementing backwardcompatargmapper and incrementing modelcheckpointversion to maintain compatibility.
Cursor rule Cursor ✓ vendor
Cannot change return types of public methods in production models, as this breaks user code that depends on the existing return type structure.
Cursor rule Cursor ✓ vendor
Every model must have CI tests verifying constructor instantiation and all public attributes (excluding buffers/parameters) using pytest parameterization.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: