Enable deterministic Newton physics - #6930
Conversation
Map --deterministic to Newton's GPU_TO_GPU mode and apply it to supported solvers and the collision pipeline. Reject unsupported solver paths instead of silently weakening the guarantee. Keep deterministic collision buffers aligned with solver contact capacity and document and test the new behavior.
github-actions
Bot
added
documentation
Greptile SummaryThis PR maps the launcher’s deterministic flag to Newton’s cross-GPU deterministic mode and propagates that setting through supported solvers and collision processing.
Confidence Score: 4/5The PR needs a fix before merging because deterministic initialization rejects subclasses of otherwise supported solver configurations. Exact class-name validation turns a supported solver configuration into an initialization error as soon as users derive a custom configuration class from it. Files Needing Attention: source/isaaclab_newton/isaaclab_newton/physics/newton_manager.py Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[--deterministic] --> B[Simulation config scan]
B --> C[NewtonCfg deterministic_mode = gpu_to_gpu]
C --> D[NewtonManager initialization]
D --> E{Solver supported?}
E -->|No| F[Raise ValueError]
E -->|Yes| G[Pass DeterministicMode to solver]
G --> H[Create deterministic collision pipeline]
H --> I[Match contact capacity to solver]
Reviews (1): Last reviewed commit: "Enable deterministic Newton physics" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| solver_cfg_type = type(solver_cfg).__name__ | ||
| if solver_cfg_type not in _DETERMINISTIC_SOLVER_CFG_TYPES: |
There was a problem hiding this comment.
When a custom configuration subclasses FeatherstoneSolverCfg, MJWarpSolverCfg, VBDSolverCfg, or XPBDSolverCfg, exact class-name validation rejects it even though it retains a supported deterministic solver, causing solver initialization to raise ValueError.
![isaaclab-review-bot[bot]](https://avatars.githubusercontent.com/u/157846462?s=60&v=4){kind=small}
There was a problem hiding this comment.
Isaac Lab Review Bot
The deterministic-mode wiring is coherent and preserves existing Newton configuration when the flag is omitted. However, the changelog does not disclose that --deterministic now rejects unsupported Newton solver configurations that previously continued running.
- Design and architecture: Determinism intent is applied during launcher scanning and translated to Warp’s enum at the Newton boundary. The fail-loud policy for Kamino, implicit MPM, and MuJoCo CPU is explicit and defensible, but it changes existing launcher behavior from advisory to run-blocking for those configurations.
- API:
NewtonCfg.deterministic_modeis validated and defaults to"not_guaranteed", while--deterministicselects"gpu_to_gpu". Because existing--deterministiccommand lines using unsupported Newton paths now raise an error, the Isaac Lab changelog must record this underChangedas a breaking behavior change and provide migration guidance. - Implementation: The implementation applies the launcher override after physics selection, forwards the resolved mode to supported solvers, enables deterministic collision ordering, and rebuilds the collision pipeline when needed to match solver contact capacity. No additional implementation defect is established by the candidate review.
Minor fixes needed. Posted 1 actionable finding inline.
Automated review; human maintainers own approval decisions.
| Added | ||
| ^^^^^ | ||
|
|
||
| * Added Newton physics handling to ``--deterministic`` so the flag selects |
There was a problem hiding this comment.
🟡 Warning · Api — Changelog omits --deterministic behavior change
--deterministic previously only affected rendering and torch determinism, so it ran fine with any Newton solver. The launcher now stamps gpu_to_gpu on every NewtonCfg, and _validate_deterministic_solver_cfg raises for Kamino, implicit MPM, and MuJoCo-CPU configs, aborting command lines that worked before. Per the changelog rules this belongs under Changed (breaking) with migration guidance, in addition to the Added entry.
…n-gpu-determinism
Keep the existing RTX launcher setting unchanged. Expose Newton determinism only through NewtonCfg. Validate supported solver config subclasses by type. Custom configurations now retain deterministic support.
StafaH
left a comment
StafaH
left a comment
There was a problem hiding this comment.
LGTM. Let's leave a comment about performance and memory limitations for turning on deterministic = True.
Also theres a test somewhere for determinism in isaaclab that can probably be turned on now for newton. The test was defaulted to physx only.
| from isaaclab_newton.physics.visualization_deformables import populate_shadow_deformable_registry | ||
|
|
||
| from .newton_manager_cfg import NewtonCfg, NewtonShapeCfg | ||
| from .featherstone_manager_cfg import FeatherstoneSolverCfg |
There was a problem hiding this comment.
Let's use absolute imports here and elsewhere
Add a bounded rough-terrain CUDA case using gpu_to_gpu mode. Document deterministic collision overhead and use absolute physics imports.
Exercise deterministic MJWarp contacts with flat AnymalD. Rough terrain requests 2.5M triangle pairs, above Newton's deterministic packing limit.
Use a small Cartpole environment and 25 steps per run so deterministic MJWarp coverage stays within the existing CI file budget.
| ) | ||
| if cls._deterministic_mode != wp.DeterministicMode.NOT_GUARANTEED: | ||
| pipeline_args["rigid_contact_max"] = _need | ||
| NewtonManager._collision_pipeline = CollisionPipeline(cls._model, **pipeline_args) |
There was a problem hiding this comment.
Would be nice to brief about why collision pipeline rebuilt is needed. Seems collision pipeline uses _sort_key_array in deterministic mode which needs to match contacts but can only created at init.
Expose the upstream sensor-disable option and require it for deterministic MJWarp runs because the current tactile sensor kernel mixes unsupported atomic reduction families. Exercise the bounded Cartpole environment with internal sensors disabled.
Document why deterministic contact sorting requires reconstructing the collision pipeline when solver contact capacity grows.
Name the collision pipeline sort-key allocation invariant that requires rebuilding the pipeline when contact capacity grows.
3 participants
Description
Add an explicit
NewtonCfg.deterministic_modesetting for Newton physics. Thenot_guaranteed,run_to_run, andgpu_to_gpuvalues map to Warp's corresponding deterministic modes.Apply the selected mode to supported Newton solver kernels and deterministic contact ordering in the collision pipeline, including matching the pipeline's deterministic sort capacity to solver contact capacity. MJWarp on the GPU, XPBD, and Featherstone are supported. Unsupported solver paths (Kamino, implicit MPM, and MJWarp's MuJoCo CPU backend) are rejected only when a Newton determinism guarantee is explicitly configured.
The existing AppLauncher
--deterministicRTX setting and behavior remain unchanged. Supported custom solver-configuration subclasses retain deterministic support.No new dependencies are required. The pinned Newton revision already provides the required solver and collision-pipeline determinism APIs.
Type of change
Screenshots
Not applicable; this is a physics-configuration change.
Validation
uv run --frozen python -m pytest source/isaaclab_newton/test/physics/test_newton_manager_abstraction.py -k deterministic -q— 8 passed, 84 deselecteduv run --isolated --extra test -- sphinx-build -W --keep-going -j auto docs docs/_build/current— build succeededuv run --frozen isaaclab -f— all hooks passed before commit and before pushChecklist
pre-commitchecks withuv run --frozen isaaclab -fsource/<pkg>/changelog.d/for every touched packageCONTRIBUTORS.mdor my name already exists there