Export a trained Isaac Lab DisplayPort task-space checkpoint with LEAPP, run it through Isaac ROS Deploy and Isaac Sim 6.0 in separate Docker containers, verify training asset parity, and record insertion video and measured results. Use for post-training simulation deployment and testing of cable insertion policies.
Set up the standalone IsaacLabTraining package from NVIDIA-ISAAC-ROS/isaacrosmanipulation, then launch, monitor, resume, evaluate, and tune DisplayPort insertion policies without a separate Isaac Lab source installation. Use for setup and campaign planning, dependency repair, curriculum or PhysX troubleshooting, video…
Reusable layers and building blocks should be placed in physicsnemo/nn, not physicsnemo/models. Examples include FullyConnected, attention layers, and UNetBlock.
Complete models composed of multiple layers should be placed in physicsnemo/models, not physicsnemo/nn. These are domain-specific or modality-specific models.
All model and layer classes must inherit from physicsnemo.Module (not torch.nn.Module directly) to ensure proper serialization, versioning, and registry functionality.
New model classes should start in physicsnemo/experimental/nn or physicsnemo/experimental/models during development, where backward compatibility is not guaranteed.
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.
Every model/layer requires comprehensive docstrings following NumPy style with Sphinx RST formatting, including all sub-rules MOD-003b through MOD-003k.
Class docstrings must contain three mandatory sections - Parameters, Forward, and Outputs. Optional sections include Notes, Examples, ..important::, and ..code-block::.
All methods must have docstrings with at least Parameters and Returns sections. Optional sections include Notes, Examples, ..important::, and ..code-block::.
Callback function parameters must include a ..code-block:: specification showing the required signature and return type, placed outside Parameters/Forward/Outputs sections.
Docstrings should use Sphinx cross-references (:class:, :func:, :meth:) to link to other code elements and external resources for better documentation connectivity.
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.
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.
All forward and public methods must validate tensor shapes at the beginning, wrapped in torch.compiler.iscompiling() guard, with standardized error messages.
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.
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.
Cannot remove or rename parameters in production models without implementing backwardcompatargmapper and incrementing modelcheckpointversion to maintain compatibility.
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: