Reviewing files that changed from the base of the PR and between 9233b83 and 2c4addb.

• newton/_src/sim/builder.py (3 hunks)
• newton/_src/utils/import_mjcf.py (1 hunks)
• newton/_src/utils/import_urdf.py (1 hunks)
• newton/_src/utils/import_usd.py (1 hunks)
• newton/examples/basic/example_basic_joints.py (3 hunks)
• newton/examples/basic/example_basic_pendulum.py (1 hunks)
• newton/examples/cloth/example_usd_mesh.py (1 hunks)
• newton/tests/test_joint_limits.py (4 hunks)
• newton/tests/test_kinematics.py (1 hunks)

• GitHub Check: Run GPU Benchmarks (Pull Request)

newton/examples/basic/example_basic_pendulum.py (1)

46-57: LGTM! Correct usage of the new articulation API.

The example correctly creates an articulation before adding links, and properly uses add_link() for bodies within the articulation.

newton/_src/utils/import_mjcf.py (1)

566-570: LGTM! Correct API usage in MJCF importer.

The change from add_body() to add_link() is correct since an articulation is created at line 916 before bodies are parsed.

newton/_src/utils/import_urdf.py (1)

358-361: LGTM! Correct API usage in URDF importer.

The change from add_body() to add_link() is correct since an articulation is created at lines 276-279 before links are added.

newton/tests/test_joint_limits.py (2)

35-37: LGTM! Correct usage of the new articulation API.

The test correctly calls add_articulation() before add_link(), following the new API pattern.

---

148-156: No changes needed—test uses correct API pattern.

The test correctly uses the established pattern of add_body() followed by add_joint_d6(parent=-1, ...). The add_body() method explicitly creates a standalone body with an internal free joint, and then add_joint_d6(parent=-1, ...) adds a D6 joint from the world to that body. This exact pattern is consistently used across multiple test files (test_ik.py, test_control_force.py, test_body_force.py, test_ik_fk_kernels.py), confirming it is the intended API usage.

newton/tests/test_kinematics.py (1)

78-79: LGTM! Correct usage of the new articulation API.

The test correctly uses add_articulation() followed by add_link() for creating bodies within articulations.

newton/examples/basic/example_basic_joints.py (3)

64-70: LGTM! Correct usage of the new articulation API.

The revolute joint demo correctly creates an articulation before adding links.

---

96-102: LGTM! Correct usage of the new articulation API.

The prismatic joint demo correctly creates an articulation before adding links.

---

131-140: LGTM! Correct usage of the new articulation API.

The ball joint demo correctly creates an articulation before adding links.

Reviewing files that changed from the base of the PR and between 2c4addb and 34154f2.

• newton/_src/sim/builder.py (3 hunks)
• newton/_src/utils/import_mjcf.py (1 hunks)
• newton/_src/utils/import_usd.py (1 hunks)
• newton/tests/test_joint_limits.py (4 hunks)
• newton/tests/test_kinematics.py (1 hunks)

• newton/_src/utils/import_mjcf.py
• newton/tests/test_kinematics.py

• GitHub Check: Run GPU Benchmarks / Run GPU Benchmarks on AWS EC2

newton/tests/test_joint_limits.py (1)

34-36: LGTM! Correct usage of the new articulation API.

The tests correctly call add_articulation() before add_link(), which aligns with the refactored ModelBuilder API. The explicit articulation creation followed by link and joint setup properly demonstrates the new workflow for constructing articulated bodies.

Also applies to: 54-56, 74-76, 92-93

newton/_src/sim/builder.py (1)

1698-1757: Implementation looks good - achieves the PR objectives.

The new add_body method correctly implements the PR's goal of simplifying free-floating body creation by:

1. Creating an articulation with an auto-generated key (line 1738)
2. Creating a link via add_link (lines 1741-1749)
3. Adding a free joint to connect the body to the world (lines 1752-1755)

The method signature matches add_link, making migration straightforward, and the docstring clearly explains the convenience wrapper behavior.

Note: Custom attributes are only passed to add_link (line 1748), not to the auto-created articulation or free joint. This is a reasonable design choice since users needing finer control can call add_articulation(), add_link(), and add_joint_free() explicitly.

Reviewing files that changed from the base of the PR and between 89a1c38 and 84609eb.

• uv.lock is excluded by !**/*.lock

• newton/_src/sim/builder.py (5 hunks)
• newton/_src/utils/import_urdf.py (8 hunks)
• newton/examples/basic/example_basic_joints.py (6 hunks)
• newton/examples/basic/example_basic_pendulum.py (1 hunks)
• newton/tests/test_equality_constraints.py (2 hunks)
• newton/tests/test_ik.py (3 hunks)
• newton/tests/test_ik_fk_kernels.py (3 hunks)
• newton/tests/test_ik_lbfgs.py (1 hunks)
• newton/tests/test_mujoco_solver.py (21 hunks)
• pyproject.toml (3 hunks)

• newton/tests/test_equality_constraints.py
• newton/examples/basic/example_basic_pendulum.py

• GitHub Check: Run GPU Benchmarks / Run GPU Benchmarks on AWS EC2
• GitHub Check: Run GPU Tests / Run GPU Unit Tests on AWS EC2

pyproject.toml (2)

120-123: Verify uv source configuration with platform markers.

The platform-specific torch source definitions use explicit indices with markers. Ensure this configuration is tested and verified to work correctly with uv and the target build environments. The indices are marked explicit = true, which is correct for PyTorch's non-standard index structure, but integration testing is recommended.

If you have a development environment, verify that uv sync or uv pip install newton[torch-cu12] correctly selects the appropriate torch wheel based on the platform.

---

65-72: torch==2.9.0+cu129 does not exist in official PyTorch releases — this dependency will fail on non-Windows platforms.

PyTorch 2.6.0 with CUDA 12.4 wheels are available and the Windows dependency is valid. However, PyTorch 2.9.0 official releases only provide CUDA 12.6, 12.8, and 13.0 builds — there is no cu129 variant. The Linux dependency on line 70 (torch==2.9.0+cu129) will not resolve and will cause installation failures.

Consider using one of the officially available CUDA versions for 2.9.0 (cu126, cu128, or cu130) or reverting to a torch version that supports cu129 if that CUDA variant is required.

⛔ Skipped due to learnings

Learnt from: shi-eric
Repo: newton-physics/newton PR: 592
File: pyproject.toml:64-70
Timestamp: 2025-08-21T15:51:07.824Z
Learning: Self-referencing optional dependencies (e.g., "package[extra]") have been supported since pip 21.2 and are valid in pyproject.toml. However, build backends differ in metadata emission: some flatten dependencies while others preserve self-references. This can affect lockfile generators and tooling. Testing with the specific build backend and dependency tools is recommended to ensure expected behavior.

Learnt from: shi-eric
Repo: newton-physics/newton PR: 660
File: pyproject.toml:54-59
Timestamp: 2025-08-27T23:32:48.670Z
Learning: In the newton project's pyproject.toml, self-referential extras (e.g., `examples = ["newton[sim]", "newton[importers]", ...]`) are normal and encouraged for dependency management, rather than inlining the dependencies.

newton/_src/sim/builder.py (2)

1750-1828: add_link implementation correctly mirrors existing body bookkeeping

add_link correctly initializes mass/inertia, inverse quantities, state (body_q, body_qd), keys, body_shapes, and body_world in a way that matches the existing body data layout, and it cleanly hooks into custom attributes with expected_frequency=BODY. This looks safe as a drop‑in for importers and multi‑body workflows that will later attach joints and articulations explicitly.

---

1941-1957: Verify current_world state management in all callers of add_joint()

The new parent/child world validation in add_joint() prevents cross-world joints by checking that bodies belong to current_world at joint creation time. Verify that all internal call sites—including helpers like add_free_joints_to_floating_bodies() and any importers—properly maintain current_world state and do not switch to a different world between body and joint creation, as this would now raise ValueError instead of succeeding silently.

newton/_src/utils/import_urdf.py (4)

106-112: Root element handling for file vs. string input is correct

Normalizing both file-based and string-based URDF inputs through urdf_root = ...getroot()/fromstring(...) and feeding that into all subsequent lookups (find, findall) is the right fix and keeps the parsing logic consistent regardless of source type.

---

276-283: Collecting joint_indices and switching to add_link cleanly supports the new articulation workflow

Initializing joint_indices once, populating it with every joint you actually create (base/floating/fixed plus all sorted URDF joints), and building links via builder.add_link(...) (with parsed BODY‑frequency custom attributes) matches the new “links first, joints next, articulation last” model. The link ordering logic using urdf_root.find(...) and the fallback to urdf_root.findall("link") also keeps behavior consistent for both joint‑ordered and unordered URDFs.

Also applies to: 334-343, 351-359

---

445-455: Joint creation order guarantees add_articulation preconditions; please keep that invariant in mind

All the joint creation branches now (a) capture the returned joint ID and (b) append it to joint_indices in the same order joints are created: base joint (if any), then the sorted URDF joints. Since ModelBuilder.add_joint* always allocates new joints with increasing indices, this guarantees that joint_indices is monotonically increasing and contiguous relative to the existing joint_type array, which is exactly what builder.add_articulation(joints=...) expects. This is correct as long as no other code interleaves joint creation between these calls; if future refactors introduce such interleaving, they’ll need to either keep appending their joint IDs into joint_indices or build a separate contiguous slice for each articulation.

Also applies to: 462-463, 468-483, 507-516, 518-526, 528-531, 545-562

---

567-577: URDF-level articulation creation matches the new post-add_articulation(joints) model

The final builder.add_articulation(...) call that uses the collected joint_indices, the URDF root’s name as the articulation key, and ARTICULATION‑frequency custom attributes parsed from urdf_root.attrib is exactly in line with the new API design. This gives URDF importers a clear, explicit articulation object and lets users attach articulation-scoped custom attributes via the usual add_custom_attribute + URDF attributes route.

newton/tests/test_mujoco_solver.py (4)

190-207: Articulated tree setup and articulation registration look correct.

The 3-link articulated tree now uses add_link for the bodies, captures all three joint indices (free + 2 revolute), and registers them in a single articulation via add_articulation([joint1, joint2, joint3]). Joint indices are contiguous and monotonically increasing, and world ownership is consistent, so this matches the documented articulation API.

Also applies to: 208-251

---

2411-2416: Mocap articulation wiring is consistent with the new builder API.

The mocap/platform setup now:

• Creates two links via add_link (mocap_body, platform_body),
• Connects them with two fixed joints (world→mocap, mocap→platform),
• Registers both joints in a single articulation via add_articulation([mocap_joint, platform_joint]).

Joint indices are contiguous and world-consistent, so articulation creation matches the documented requirements and should keep newton_body_to_mocap_index and MuJoCo mocap arrays coherent.

Also applies to: 2419-2441, 2453-2455

---

2735-2749: Limit-margin from code: articulation wiring is correct.

test_limit_margin_from_code now:

• Creates 3 links via add_link,
• Captures their revolute joint indices (j0, j1, j2),
• Registers a single 3-joint articulation with builder.add_articulation([j0, j1, j2]).

Joint indices are contiguous and in increasing order, so the articulation definition is valid and consistent with the new builder semantics.

---

2857-2867: Limit-margin runtime update: articulation definition is valid.

For test_limit_margin_runtime_update, the builder now:

• Creates two links with revolute joints j0 and j1,
• Calls builder.add_articulation([j0, j1]) before finalize().

This ensures the joint pair is grouped in a single articulation and keeps the runtime limit_margin updates well-defined over the articulation’s DOFs.

newton/tests/test_ik_fk_kernels.py (1)

79-83: _add_single_joint articulation wiring is correct and uses joint_count appropriately.

Switching to add_link(...) for the child body, capturing ji = builder.joint_count, and then conditionally creating a single-joint articulation via

if ji == builder.joint_count - 1:
    builder.add_articulation([ji])

is consistent with the new API. Given the helper is only used on a fresh ModelBuilder, ji will always be the index of the just-added joint, and the articulation definition is contiguous and monotonic. Using builder.joint_count as an attribute matches the documented property-based interface.

Also applies to: 92-93, 149-151

newton/tests/test_ik_lbfgs.py (1)

32-57: IK L-BFGS builder helpers correctly migrate to add_link + explicit articulations.

Across _build_two_link_planar, _build_free_plus_revolute, and _build_single_d6:

• Links are now created with add_link(...) instead of add_body(...).
• Joint indices (joint1, joint2, joint) are captured.
• Articulations are registered explicitly via builder.add_articulation([...]) with contiguous, monotonically increasing joint lists.

This matches the new ModelBuilder API and keeps the test models’ articulation structure well-defined for the L-BFGS IK solver.

Also applies to: 36-42, 44-57, 56-57, 65-83, 73-80, 82-83, 91-101

newton/tests/test_ik.py (1)

39-71: IK convergence/Jacobian tests now build models with explicit articulations; wiring looks correct.

• _build_two_link_planar, _build_free_plus_revolute, and _build_single_d6 have been migrated to add_link(...) plus explicit joint capture and add_articulation([joint_indices...]), with contiguous, monotonically increasing joint lists.
• _fk_end_effector_positions’s updated signature to accept model (used only to document array shape) does not alter behavior and keeps FK post-processing consistent.

These changes align the IK tests with the new articulation-centric ModelBuilder API without introducing observable behavioral regressions.

Also applies to: 79-113, 121-135, 143-156

Reviewing files that changed from the base of the PR and between 84609eb and a092a7f.

• uv.lock is excluded by !**/*.lock

• newton/_src/utils/import_mjcf.py (4 hunks)
• newton/tests/test_model.py (9 hunks)
• newton/tests/test_mujoco_solver.py (22 hunks)

newton/_src/utils/import_mjcf.py (1)

655-659: MJCF importer articulation wiring looks consistent with new API.

• Using builder.add_link(...) for bodies (Line 655) and collecting all joint handles into joint_indices at each add_joint_* call (Lines 690-707, 713-715, 723-729, 732-743) keeps joint indices monotone and contiguous by construction.
• Initializing joint_indices = [] once (Line 1022) and creating a single articulation from it at the end (Lines 1132-1135) matches ModelBuilder.add_articulation’s expectations and avoids the empty-articulation case.
• Dict-based base_joint now correctly uses child=link before adding the joint (Lines 701-707), aligning the joint child with the created link index.

I don’t see functional or topology issues here; this importer should produce a valid articulation for the imported MJCF model.

Also applies to: 690-707, 713-715, 723-729, 732-743, 1022-1023, 1132-1135

newton/tests/test_mujoco_solver.py (3)

45-49: Single‑joint test setups now follow the explicit articulation model.

Across test_ls_parallel_option, test_tolerance_options, test_no_shapes, and test_separate_worlds_false_single_world_works, the pattern:

• link = builder.add_link(...)
• joint = builder.add_joint_* (-1, link, ...)
• builder.add_articulation([joint])

creates a minimal, well‑formed 1‑joint articulation that satisfies the contiguity/monotonicity constraints and matches the new ModelBuilder contract. This looks correct and keeps the tests aligned with the new API.

Also applies to: 62-67, 1821-1824, 1859-1865

---

189-253: Template builder articulations for MuJoCo property tests look structurally sound.

• In TestMuJoCoSolverPropertiesBase.setUp (Lines 189-253) and test_jnt_solimp_conversion_and_updates (Lines 774-820), you now:
  • Keep the free box as a standalone body via add_body(...) (which owns its own free‑joint articulation).
  • Build a 3‑link tree via add_link(...) + add_joint_free/add_joint_revolute and register it once with add_articulation([joint1, joint2, joint3]).
• In test_separate_worlds_false_multi_world_validation (Lines 1831-1836), the template builder similarly creates a link, a revolute joint to world, and a dedicated articulation.

In all three, joint indices are contiguous/monotone, the trees are valid (each child has a single parent), and the free body and articulated tree are cleanly separated into distinct articulations. This matches the new articulation semantics and should work well with the MuJoCo solver’s multi‑world replication.

Also applies to: 774-820, 1831-1836

---

2525-2571: Mocap, custom‑attribute, and limit‑margin tests correctly use explicit articulations.

• In test_mocap_body_transform_updates_collision_geoms (Lines 2525-2571), grouping the world‑fixed mocap_joint and the platform_joint into a single articulation via builder.add_articulation([mocap_joint, platform_joint]) yields a clean fixed‑base tree for the mocap body and its welded descendant, while the dynamic ball remains a separate free‑body articulation via add_body(...). This matches the intended “fixed base articulation + dynamic body” setup.
• In test_custom_attributes_from_code, test_limit_margin_from_code, and test_limit_margin_runtime_update (Lines 2719-2729, 2853-2866, 2975-2984), the link/joint chains are built with add_link + add_joint_revolute, and all relevant joints are registered once via add_articulation([...]). Joint indices are contiguous/monotone and the trees are simple chains, so they satisfy add_articulation’s validation.

These changes look correct and give MuJoCo a clear articulation structure to work with for attribute propagation.

Also applies to: 2719-2729, 2853-2866, 2975-2984

newton/tests/test_model.py (4)

119-137: Fixed‑joint collapse and builder replication tests are aligned with the new articulation model.

• add_three_cubes now builds three links via add_link() and returns the fixed‑joint indices (Lines 119-137), which you then:
  • Use as a full articulation of only fixed joints.
  • Extend with a revolute joint for a mixed fixed/non‑fixed articulation.
  • Combine with a free joint for a third articulation (Lines 140-171).
• The expected post‑collapse counts and contents (joint_count/body_count/articulation_start/joint_type/body_com/body_mass, Lines 174-185) are consistent with the described topology.
• test_add_builder (Lines 566-571) now constructs both fixed‑base and floating‑base sub‑builders with explicit articulations (add_articulation([j0]), add_articulation([j1])), and the assertions on counts, worlds, parent/child indices, and transforms all match the intended two‑articulation configuration.

These tests give good coverage of articulation behavior before/after collapse_fixed_joints and through add_builder, and they look correct with the new API.

Also applies to: 140-171, 186-198, 566-571

---

316-335: World‑grouping expectations match updated add_body + articulation behavior.

• In test_world_grouping, the global ground is still created via main_builder.add_body(...) in world -1, which now implies:
  • A free joint for the ground body.
  • A dedicated articulation for that joint.
• Each create_world_builder() call (Lines 330-335) builds a 2‑link articulated body via add_link + add_joint_revolute and registers it with add_articulation([j1]).

With three cloned worlds plus the global ground, the revised expectations:

• joint_count == 4 and articulation_count == 4 (Lines 370-371).
• joint_world == [-1, 0, 1, 2] and articulation_world == [-1, 0, 1, 2] (Lines 405-415).

are consistent with one articulation per world (and one for the global ground). The grouping assertions across particles, bodies, shapes, joints, and articulations correctly reflect the new semantics.

Also applies to: 365-372, 405-415

---

461-544: Group‑aware fixed‑joint collapse scenario is well‑specified.

In test_collapse_fixed_joints_with_groups:

• World 0 chain: three links with a revolute joint to world, followed by a fixed and then a revolute joint (Lines 461-489), grouped into an articulation (Lines 490-492).
• World 1 chain: two links with a revolute joint to world and a revolute joint between bodies, plus its own articulation (Lines 495-517).
• Global body: created via add_body(...) in world -1 (Lines 519-523), which adds a free‑joint articulation for the global body.

Pre‑collapse checks on body_world and joint_world (Lines 525-527) match this layout. After collapse_fixed_joints:

• The expected reduced body_count == 5 and joint_count == 5 (Lines 538-540).
• Updated body_world and joint_world arrays (Lines 542-543).

all line up with the comments describing which body/joint was removed and how the merged bodies are grouped. The follow‑up checks on the finalized model confirm that world groups are preserved correctly through collapse and finalize.

This is a solid regression test for group‑aware fixed‑joint collapsing with a global body still present.

---

612-713: New articulation and joint world‑validation tests closely mirror ModelBuilder’s contract.

The added tests:

• test_articulation_validation_contiguous, test_articulation_validation_monotonic, test_articulation_validation_empty, test_articulation_validation_world_mismatch, and test_articulation_validation_tree_structure (Lines 612-713) exercise:
  • Non‑contiguous joint lists (gap in indices).
  • Non‑monotonic lists (wrong order).
  • Empty joint lists.
  • Cross‑world joint mixes.
  • Multiple‑parent situations for a single child body.
• test_joint_world_validation (Lines 715-729) validates that joint creation fails when parent/child bodies don’t belong to the builder’s current world.

The asserted substrings in the error messages (“contiguous”, “monotonically increasing”, “no joints”, “world”, “multiple parents”) match the messages emitted by ModelBuilder.add_articulation and the new joint world checks. This suite gives good negative‑case coverage for the updated API invariants and should help catch future regressions.

Also applies to: 715-729

Reviewing files that changed from the base of the PR and between a092a7f and 9ad4a07.

• newton/tests/test_mujoco_solver.py (24 hunks)

• GitHub Check: Run GPU Tests / Run GPU Unit Tests on AWS EC2
• GitHub Check: Run GPU Benchmarks / Run GPU Benchmarks on AWS EC2

newton/tests/test_mujoco_solver.py (11)

46-48: LS/tolerance tests now correctly build a minimal articulation

Both test_ls_parallel_option and test_tolerance_options now create a single-link, single-revolute-joint articulation via add_link → add_joint_revolute → add_articulation([joint]). That matches the new articulation-first API and gives MuJoCo exactly one DOF as intended.

Also applies to: 63-65

---

776-777: Solimp test now builds a proper articulated chain

The solimplimit test’s template builder now uses add_link + add_joint_free + two revolute joints, and registers them together via add_articulation([joint1_idx, joint2_idx, joint3_idx]). That fixes the earlier missing-articulation pattern and ensures all DOFs in the tree participate in articulation-based MuJoCo mapping (via dof_to_mjc_joint).

Also applies to: 785-789, 791-795, 805-809, 819-820

---

1009-1013: Passive stiffness/damping multiworld test uses articulation-aware template

The pendulum template now consists of a single link, one revolute joint to world, and an articulation created with add_articulation([joint]). Replication across worlds will therefore produce clean, per-world articulations, which is exactly what the multiworld stiffness/damping checks assume.

Also applies to: 1021-1027, 1028-1033

---

1822-1824: Minimal prismatic model correctly migrated off add_body

test_no_shapes now uses add_link + add_joint_prismatic(-1, b) with add_articulation([j]), giving a single-DOF articulated body with no shapes. This matches the intent of the test and avoids the implicit free-joint articulation that add_body now creates.

---

1833-1836: Multi-world validation template builder now creates an articulation

The template used in test_separate_worlds_false_multi_world_validation now wires its single revolute joint into an articulation via add_articulation([joint]), which is important for exercising solver behavior under separate_worlds in an articulation-based model.

---

1862-1865: Single-world separate_worlds=False test aligned with new API

The single-world test now builds a one-link, one-revolute-joint articulation via add_link → add_joint_revolute → add_articulation([j]). That keeps the DOF count (mj_model.nv == 1) clear and consistent with articulation-based wiring.

---

2216-2222: Noncontiguous-joint indexing test builds a minimal articulation correctly

The robot fixture now uses add_link twice and a single revolute joint, then registers that joint via robot.add_articulation([0]). For this test—focused on selection and indexing of joints across worlds—that’s exactly what you need: one simple articulated chain per replicated robot.

---

2529-2537: Mocap/platform tree is now an explicit articulation

In the mocap test, you now:

• Create mocap_body and platform_body via add_link.
• Connect them with two fixed joints (mocap_joint, platform_joint).
• Register an articulation with builder.add_articulation([mocap_joint, platform_joint]).

This cleanly models the fixed-base mocap tree as its own articulation, while the dynamic ball continues to use add_body (and its implicit articulation). That matches how the solver identifies and updates mocap bodies.

Also applies to: 2546-2558, 2571-2572

---

2720-2721: Custom-attribute chain from code wired as a single articulation

test_custom_attributes_from_code now builds a 3-link chain via add_link + revolute joints and groups all three joints in add_articulation([j0, j1, j2]). This is the right shape for testing joint/geom custom attributes (like condim) across an articulated chain.

Also applies to: 2723-2724, 2726-2727, 2729-2729

---

2854-2856: Limit-margin-from-code test now uses a well-formed 3‑joint articulation

The limit-margin test builds three links, three revolute joints (two with custom margins, one default), and registers them via builder.add_articulation([j0, j1, j2]). That guarantees all tested joints are part of the same articulation and show up consistently in both Newton and MuJoCo arrays.

Also applies to: 2858-2860, 2862-2864, 2866-2867

---

2976-2978: Runtime limit-margin update test uses a 2‑joint articulation

Similarly, the runtime update test now creates two links and revolute joints and wires them into a single articulation. This keeps model.mujoco.limit_margin and mjw_model.jnt_margin in 1‑1 correspondence for the DOFs under test, making the update assertions robust.

Also applies to: 2980-2982, 2984-2985

Reviewing files that changed from the base of the PR and between 9ad4a07 and 0931062.

• newton/tests/test_mujoco_solver.py (24 hunks)

• GitHub Check: Run GPU Benchmarks / Run GPU Benchmarks on AWS EC2
• GitHub Check: Run GPU Tests / Run GPU Unit Tests on AWS EC2

newton/tests/test_mujoco_solver.py (8)

46-48: Articulation setup for basic solver option tests looks correct

Using add_link(...), a world-attached revolute joint, and add_articulation([joint]) produces a minimal 1‑DOF articulation for both tests, which matches the new post‑add_articulation(joints) workflow and keeps the MuJoCo option checks focused on solver behavior rather than builder quirks.

Also applies to: 63-65

---

192-253: Multi‑world template builder now cleanly separates free body and articulated tree

Switching the free box to add_body(..., xform=...) and the 3‑link chain to add_link(...) + add_joint_* + add_articulation([joint1, joint2, joint3]) gives you exactly one free‑floating articulation plus one tree articulation per world. That aligns with the new API semantics and keeps body indices for the articulated chain contiguous and monotonic as required.

---

774-820: jnt_solimp test builder follows the new articulation workflow

The template builder now creates:

• one free‑floating body via add_body(...), and
• a 3‑link articulated chain via add_link + add_joint_free/add_joint_revolute + add_articulation([joint1_idx, joint2_idx, joint3_idx]).

This matches the post‑add_articulation(joints) design and ensures the DOF‑to‑MuJoCo‑joint mapping exercised later in the test is well‑defined across replicated worlds.

---

1006-1035: Pendulum template for passive stiffness/damping test is wired correctly

The updated template builder (add_link + world‑attached revolute + add_articulation([joint]), then replicated to multiple worlds) cleanly produces one articulated pendulum per world, which fits the assumptions in the passive stiffness/damping checks and the joint_mjc_dof_start/dof_to_mjc_joint mapping.

---

2523-2572: Mocap body + platform articulation wiring looks consistent with new API

Defining the mocap root and platform via add_link(...), connecting them with two FIXED joints, and then calling builder.add_articulation([mocap_joint, platform_joint]) cleanly encodes the fixed‑base mocap articulation. The dynamic ball is still created via add_body(...), which now naturally lives in its own free‑floating articulation. This matches the test’s intent and should keep newton_body_to_mocap_index and the mocap_pos/mocap_quat updates well‑defined.

---

2718-2730: Custom attribute test now uses an explicit 3‑joint articulation

Creating three links, wiring them with two internal revolute joints plus a world‑attached root revolute, and registering [j0, j1, j2] as a single articulation is a good fit for exercising mujoco:condim propagation. The articulation grouping matches how the solver will see the chain, so the condim checks on both the Newton model and mjw_model look sound.

---

2850-2867: limit_margin‑from‑code test correctly builds and registers a 3‑joint chain

The switch to add_link() plus add_joint_revolute(...) for b0, b1, and b2, followed by builder.add_articulation([j0, j1, j2]), makes this test’s articulation structure explicit and consistent with how limit_margin is stored and mapped to jnt_margin. The expected [0.01, 0.02, 0.0] pattern should remain stable under this wiring.

---

2970-2985: Runtime limit_margin update test uses consistent articulation wiring

Reusing the add_link + two revolute joints + add_articulation([j0, j1]) pattern here keeps the runtime update path (notify_model_changed(SolverNotifyFlags.JOINT_DOF_PROPERTIES)) aligned with the static limit_margin tests. The builder/solver setup now clearly encodes a 2‑joint articulation, so the before/after jnt_margin comparisons are testing exactly what they should.