Fix typos and minor corrections in MuJoCo documentation and comments.

PiperOrigin-RevId: 875163889
Change-Id: Ic604d6235bf9cb999058f191e3ee41e47ec1a567

doc/APIreference/APItypes.rst

@@ -18,7 +18,7 @@ MuJoCo defines a large number of types:
   Note that the API does not use these enum types directly. Instead it uses ints, and the documentation/comments state
   that certain ints correspond to certain enum types. This is because we want the API to be compiler-independent, and
   the C standard does not dictate how many bytes must be used to represent an enum type. Nevertheless, for improved
-  readiblity, we recommend using these types when calling API functions which take them as arguments.
+  readability, we recommend using these types when calling API functions which take them as arguments.
 
 - :ref:`C struct types<tyStructure>`. These can be classified as:
 
@@ -806,7 +806,7 @@ Struct types
 ------------
 
 The three central struct types for physics simulation are :ref:`mjModel`, :ref:`mjOption` (embedded in :ref:`mjModel`)
-and :ref:`mjData`. An introductory discussion of these strucures can be found in the :ref:`Overview<ModelAndData>`.
+and :ref:`mjData`. An introductory discussion of these structures can be found in the :ref:`Overview<ModelAndData>`.
 
 
 .. _mjModel:
@@ -1708,7 +1708,7 @@ mjfOpenResource
 
    typedef int (*mjfOpenResource)(mjResource* resource);
 
-This callback is for opeing a resource; returns zero on failure.
+This callback is for opening a resource; returns zero on failure.
 
 .. _mjfReadResource:
 

doc/XMLreference.rst

@@ -1005,7 +1005,7 @@ compilation.
    This attribute specifies the maximum number of contacts that will be generated at runtime.  If the number of active
    contacts is about to exceed this value, the extra contacts are discarded and a warning is generated.  This is a
    deprecated legacy attribute which prior to version 2.3.0 affected memory allocation. It is kept for backwards
-   compatibillity and debugging purposes.
+   compatibility and debugging purposes.
 
 .. _size-nstack:
 
@@ -1992,7 +1992,7 @@ attribute and :el:`layer` child elements is an error.
         - opacity (alpha channel)
       * - :at:`emissive`
         - 4
-        - RGB light emmision intensity, exposure weight in 4th channel
+        - RGB light emission intensity, exposure weight in 4th channel
       * - :at:`orm`
         - 3
         - packed 3 channel [occlusion, roughness, metallic]
@@ -3676,7 +3676,7 @@ saving the XML:
 
    **direct** allows the user to specify the point and element data of the flexcomp directly in the XML. Note that
    flexcomp will still generate moving bodies automatically, as well as automate other settings; so it still provides
-   convenience compared to specifing the corresponding flex directly.
+   convenience compared to specifying the corresponding flex directly.
 
 .. _body-flexcomp-count:
 
@@ -3869,7 +3869,7 @@ multiple times is allowed.
 .. _flexcomp-pin-id:
 
 :at:`id`: :at-val:`int(n), required`
-   Zero-based ids of points to pin. When the points are automatically-generaged, the user needs to understand their
+   Zero-based ids of points to pin. When the points are automatically-generated, the user needs to understand their
    layout in order to decide which points to pin. This can be done by first creating a flexcomp without any pins,
    loading it in the simulator, and showing the body labels.
 
@@ -4455,7 +4455,7 @@ be clear from the above specification.
 .. _deformable-skin-face:
 
 :at:`face`: :at-val:`int(3*nface), optional`
-   Trinagular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1.
+   Triangular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1.
 
 .. _deformable-skin-inflate:
 
@@ -6608,7 +6608,7 @@ points (spheres) and the surface normals (arrows).
      regardless of the ray origin. If this data type is included along with either :at-val:`dist` or :at-val:`point`,
      normals will be visualized as arrows at the intersection points.
    - :at-val:`depth`: **real(1)**: The distance of the hit point from the camera plane, -1 if no surface was hit. Note
-     that this depth sematic corresponds to depth images in the computer graphics sense.
+     that this depth semantic corresponds to depth images in the computer graphics sense.
 
 .. _sensor-rangefinder-name:
 
@@ -7864,7 +7864,7 @@ See :ref:`collision-sensors` for more details about sensors of this type.
 .. _sensor-distance-cutoff:
 
 :at:`cutoff`
-   See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories.
+   See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories.
    If no collision is detected, the distance sensor returns the :at:`cutoff` value, so in this case
    :at:`cutoff` acts as a maximum clipping value, in addition to the special semantics.
 
@@ -7919,7 +7919,7 @@ See :ref:`collision-sensors` for more details about sensors of this type.
 .. _sensor-normal-cutoff:
 
 :at:`cutoff`
-   See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories.
+   See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories.
    If no collision is detected, the :ref:`normal<sensor-normal>` sensor returns (0, 0, 0), otherwise it returns a
    normalized direction vector. For this sensor, :at:`cutoff` does not lead to any clamping.
 
@@ -7975,7 +7975,7 @@ See :ref:`collision-sensors` for more details about sensors of this type.
 .. _sensor-fromto-cutoff:
 
 :at:`cutoff`
-   See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories.
+   See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories.
    If no collision is detected, the :ref:`fromto<sensor-fromto>` sensor returns 6 zeros.
    For this sensor, :at:`cutoff` does not lead to any clamping.
 

doc/changelog.rst

@@ -1095,7 +1095,7 @@ General
    forces on the joint are treated as applied by actuators. See attribute documentation for more details. The example
    model
    `refsite.xml <https://github.com/google-deepmind/mujoco/blob/main/test/engine/testdata/actuation/refsite.xml>`__,
-   which demostrates Cartesian actuation of an arm, has been updated to use this attribute.
+   which demonstrates Cartesian actuation of an arm, has been updated to use this attribute.
 3. Added support for gmsh format 2.2 , tetrahedral mesh, as generated by e.g. `fTetwild <https://github.com/wildmeshing/fTetWild>`__.
 
 4. Added :ref:`mju_euler2Quat` for converting an Euler-angle sequence to quaternion.
@@ -2620,7 +2620,7 @@ UI
 11. Figure selection type changed from ``int`` to ``float``.
 #. Figures now show data coordinates, when selection and highlight are enabled.
 #. Changed ``mjMAXUIMULTI`` to 35, ``mjMAXUITEXT`` to 300, ``mjMAXUIRECT`` to 25.
-#. Added collapsable sub-sections, implemented as separators with state: ``mjSEPCLOSED`` collapsed, ``mjSEPCLOSED+1``
+#. Added collapsible sub-sections, implemented as separators with state: ``mjSEPCLOSED`` collapsed, ``mjSEPCLOSED+1``
    expanded.
 #. Added ``mjITEM_RADIOLINE`` item type.
 #. Added function ``mjui_addToSection`` to simplify UI section construction.

doc/computation/fluid.rst

@@ -72,7 +72,7 @@ body coordinates are
    g_{V, i} = \quad &- 8 \beta \pi r_{eq}^3 \omega_i \\
    \end{aligned}
 
-One can also affect these forces by specifing a non-zero :ref:`wind<option-wind>`, which is a 3D vector subtracted
+One can also affect these forces by specifying a non-zero :ref:`wind<option-wind>`, which is a 3D vector subtracted
 from the body linear velocity in the fluid dynamics computation.
 
 .. _flEllipsoid:
@@ -357,7 +357,7 @@ of symmetry because under this assumption the kinetic energy greatly simplifies
 
 .. math::
    2 \mathcal{T} = m_{A, x} v_x^2 + m_{A, y} v_y^2 + m_{A, z} v_z^2 +
-                 I_{A, x} \omega_x^2 + I_ {A, y} \omega_y^2 + I_{A, y} \omega_z^2
+                 I_{A, x} \omega_x^2 + I_ {A, y} \omega_y^2 + I_{A, z} \omega_z^2
 
 
 For convenience we introduce the added-mass vector :math:`\mathbf{m}_A = \{m_{A, x}, m_{A, y}, m_{A, z}\}` and added-moment of
@@ -429,7 +429,7 @@ bagheri2016`. See screen capture of the
 We derive a formula for :math:`\mathbf{f}_\text{D}` based on two surfaces :math:`A^\text{proj}_\mathbf{v}` and
 :math:`A_\text{max}`. The first, :math:`A^\text{proj}_\mathbf{v}`, is the cylindrical projection of the body onto a
 plane normal to the velocity :math:`\mathbf{v}`. The second is the maximum projected surface
-:math:`A_\text{max} = 4 \pi r_{max} r_{min}`.
+:math:`A_\text{max} = \pi r_{max} r_{mid}`.
 
 .. math::
    \mathbf{f}_\text{D} = - \rho~ \big[  C_{D, \text{blunt}} ~ A^\text{proj}_\mathbf{v} ~ +
@@ -541,7 +541,7 @@ onto the surface. The lift force per unit length can be computed with the Kutta
 :math:`\mathbf{f}_K / L = \rho \Gamma_\text{K} \times \mathbf{v}`.
 
 In order to extend the lift force equation to three-dimensional motions, we consider the normal
-:math:`\mathbf{n}_{s, \mathbf{v}} = \{\frac{r_y r_z}{r_x}v_x, \frac{r_z r_x}{r_y}v_y, \frac{r_x r_x}{r_z}v_z\}`
+:math:`\mathbf{n}_{s, \mathbf{v}} = \{\frac{r_y r_z}{r_x}v_x, \frac{r_z r_x}{r_y}v_y, \frac{r_x r_y}{r_z}v_z\}`
 to the cross-section of the body which generates the body's projection :math:`A^\text{proj}_\mathbf{v}` onto a plane
 normal to the velocity given in the :ref:`lemma<flProjection>` above and the corresponding unit vector
 :math:`\hat{\mathbf{n}}_{s, \mathbf{v}}`.

doc/computation/index.rst

@@ -531,7 +531,7 @@ All three single-step integrators in MuJoCo use the update :eq:`eq_implicit_upda
 Semi-implicit with implicit joint damping (``Euler``)
    For this method, :math:`D` only includes derivatives of joint damping. Note that in this case :math:`D` is diagonal
    and :math:`\widehat{M}` is symmetric, so :math:`L^TL` decomposition (a variant of Cholesky) can be used. This
-   factorization is stored ``mjData.qLD``. If the model has no joint damping or the
+   factorization is stored in ``mjData.qH``. If the model has no joint damping or the
    :ref:`eulerdamp<option-flag-eulerdamp>` disable-flag is set, implicit damping is disabled and the semi-implicit
    update :eq:`eq_semimplicit` is used, rather than :eq:`eq_implicit_update`, avoiding the additional factorization of
    :math:`\widehat{M}` (*additional* because :math:`M` is already factorized for the acceleration update
@@ -579,11 +579,11 @@ Fast implicit-in-velocity (``implicitfast``)
     step is "just right", but that range is model-dependent.
 
    :ref:`integrator<option-integrator>`
-    Summary: The recommended integrator is ``implicitfast`` which usually has the best tradeoff of stabillity and
+    Summary: The recommended integrator is ``implicitfast`` which usually has the best tradeoff of stability and
     performance.
 
     **Euler**:
-     Use ``Euler`` for compatibillity with older models.
+     Use ``Euler`` for compatibility with older models.
     **implicitfast**:
      The ``implicitfast`` integrator has similar computational cost to ``Euler``, yet provides
      increased stability, and is therefore a strict improvement. It is the recommended integrator for most models.
@@ -839,14 +839,14 @@ as defined later. The ``condim`` parameter determines the contact type, and has
 
 ``condim = 3`` : 3 for elliptic, 4 for pyramidal
    This is a regular frictional contact, which can generate normal force as well as a tangential friction force opposing
-   slip. An interpertation of this number is the slope of a surface above which a flat object will begin to slip
+   slip. An interpretation of this number is the slope of a surface above which a flat object will begin to slip
    under gravity.
 
 ``condim = 4`` : 4 for elliptic, 6 for pyramidal
    In addition to normal and tangential force, this contact can generate torsional friction torque opposing rotation
    around the contact normal, corresponding to a torque generated by a contacting surface patch. This is useful for
    modeling soft fingers, and can substantially improve the stability of simulated grasping. Torsional friction
-   coefficients have **units of length** which can be interperted as the diameter of the surface contact patch.
+   coefficients have **units of length** which can be interpreted as the diameter of the surface contact patch.
 
 ``condim = 6`` : 6 for elliptic, 10 for pyramidal
    This contact can oppose motion in all relative degrees of freedom between the two geoms. In particular it adds

doc/includes/references.h

@@ -571,7 +571,7 @@ typedef enum mjtTextureRole_ {    // role of texture map in rendering
   mjTEXROLE_ROUGHNESS,            // roughness
   mjTEXROLE_METALLIC,             // metallic
   mjTEXROLE_NORMAL,               // normal (bump) map
-  mjTEXROLE_OPACITY,              // transperancy
+  mjTEXROLE_OPACITY,              // opacity
   mjTEXROLE_EMISSIVE,             // light emission
   mjTEXROLE_RGBA,                 // base color, opacity
   mjTEXROLE_ORM,                  // occlusion, roughness, metallic

doc/modeling.rst

@@ -495,7 +495,7 @@ are as follows:
    in mjData.contact actually has all 5 of them, even if condim is less than 6 and not all coefficients are used. In
    contrast, geoms have only 3 friction coefficients: tangential (same for both axes), torsional, rolling (same for both
    axes). Each of these 3D vectors of friction coefficients is expanded into a 5D vector of friction coefficients by
-   replicating the tangetial and rolling components. See the :ref:`Contact<coContact>` section in the Computation
+   replicating the tangential and rolling components. See the :ref:`Contact<coContact>` section in the Computation
    chapter for an intuitive description of the semantics of tangential, torsional and rolling coefficients.
 
    The contact friction coefficients are then computed according to the following rule: if one of the two geoms has
@@ -1113,7 +1113,7 @@ Here we describe the XML attributes common to all sensor types, so as to avoid r
 :at:`noise`: :at-val:`real, "0"`
    The standard deviation of the noise model of this sensor. In versions prior to 3.1.4, this would lead to noise being
    added to the sensors. In release 3.1.4 this feature was removed, see :doc:`3.1.4 changelog <changelog>` for a
-   detailed justification. As of subsequent versions, this attrbute serves as a convenient location for saving standard
+   detailed justification. As of subsequent versions, this attribute serves as a convenient location for saving standard
    deviation information for later use.
 
 .. _sensor-cutoff:
@@ -1454,7 +1454,7 @@ that applies to all edges of a given flex, which permits large time steps, or a
 where each element is in a constant stress state, which is equivalent to piecewise linear finite elements and achieves
 improved realism and accuracy. The edge-based model could be seen as a "lumped" stiffness model, where the correct
 coupling of deformation modes (e.g. shear and volumetric) is averaged in a single quantity. The continuum model enables
-instead to specify shear and volumetic stiffnesses separately using the `Poisson's ratio
+instead to specify shear and volumetric stiffnesses separately using the `Poisson's ratio
 <https://en.wikipedia.org/wiki/Poisson%27s_ratio>`__ of the material. For more details, see the `Saint Venant-Kirchhoff
 <https://en.wikipedia.org/wiki/Hyperelastic_material#Saint_Venant%E2%80%93Kirchhoff_model>`__ hyperelastic model.
 
@@ -1631,7 +1631,7 @@ perfectly (and much better than a spring-damper would) because the constraints a
 large forces without destabilizing the simulation. But if the hand is forced to make contact with the table for example
 (right plot) it cannot simultaneously respect the contact constraint and track the mocap body. This is because the
 mocap body is free to go through the table. So which constraint wins? That depends on the softness of the weld
-constraint realtive to the contact constraint. The corresponding :at:`solref` and :at:`solimp` parameters need to be
+constraint relative to the contact constraint. The corresponding :at:`solref` and :at:`solimp` parameters need to be
 adjusted so as to achieve the desired trade-off. See the Modular Prosthetic Limb (MPL) hand model available on the
 MuJoCo Forum for an example; the plots below are generated with that model.
 
@@ -1735,7 +1735,7 @@ dedicated section :ref:`therein<MjxPerformance>`.
 
    - Reduce the number of checked collisions using the
      :ref:`contype<body-geom-contype>` / :ref:`conaffinity<body-geom-conaffinity>` mechanism described in the
-     :ref:`Collison detection<Collision>` section.
+     :ref:`Collision detection<Collision>` section.
    - Modify collision geometries, replacing expensive collision tests (e.g. mesh-mesh) with cheaper primitive-primitive
      collisions. As a rule of thumb, collisions which have custom pair functions in the collision table at the top of
      `engine_collision_driver.c <https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_collision_driver.c>`__
@@ -1766,7 +1766,7 @@ better visualize and understand the contact configuration and resulting forces.
 **Slip-preventing contact forces are outside the friction cone**
   This implies that the physics cannot prevent slip, even in principle. This occurs when:
 
-  a. *The normal force is too small.* Ensure that the maximum force that can be applied by the gripper mutiplied by
+  a. *The normal force is too small.* Ensure that the maximum force that can be applied by the gripper multiplied by
      the sliding friction coefficient is significantly greater than the weight of the object.
   b. *The sliding friction coefficient is too low.* Increase the sliding :ref:`friction<body-geom-friction>`
      coefficient.
@@ -1774,7 +1774,7 @@ better visualize and understand the contact configuration and resulting forces.
      4 or 6 and choose appropriate friction coefficients.
      **condim 4** enables torsional friction, preventing rotation around the normal.
      **condim 6** also enables rolling friction, preventing rotation around the tangential directions.
-     See the :ref:`Contact<coContact>` section for details and the specifc semantics of these coefficients.
+     See the :ref:`Contact<coContact>` section for details and the specific semantics of these coefficients.
 
 **The geometry does not support the required forces or torques**
   This is a common real-world problem, solved by improved design of grippers and handles.
@@ -1790,7 +1790,7 @@ better visualize and understand the contact configuration and resulting forces.
   High-frequency, low-amplitude vibrations are also a real-world problem in many industrial settings, but unlike in
   simulation, in the real world they are audible. Such vibration is often caused by controllers with very
   high gains and sometimes by stick-slip feedback from contacts or joints, resonating with the eigen-modes of the
-  mechanism. The easist way to diagnose such vibration is to visualize contact forces in
+  mechanism. The easiest way to diagnose such vibration is to visualize contact forces in
   :ref:`simulate<saSimulate>`. The solution is usually to reduce the :ref:`timestep<option-timestep>` and/or add
   some :ref:`armature<body-joint-armature>` to the relevant joints. Another reason for vibration is feedback from
   explicit damping. Use the implicit or implicitfast integrators, as documented in the

doc/programming/modeledit.rst

@@ -160,7 +160,7 @@ or :ref:`attach a frame or an mjSpec to a body<mjs_attach>`:
 
 Note that in the above examples, the parent and child models have different values for ``compiler.degree``,
 corresponding to the :ref:`compiler/angle<compiler-angle>` attribute, specifying the units in which angles are
-interperted. Compiler flags are carried over during attachment, so the child model will be compiled using the child
+interpreted. Compiler flags are carried over during attachment, so the child model will be compiled using the child
 flags, while the parent will be compiled using the parent flags.
 
 Note also that once a child is attached by reference to a parent, the child cannot be compiled on its own.

doc/programming/samples.rst

@@ -210,7 +210,7 @@ data file into a playable movie file:
 Note that the offscreen rendering resolution of the model and ffmpeg's video_size must be identical.
 
 This sample can be compiled in three ways which differ in how the OpenGL context is created: using GLFW with an
-invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are envoked by
+invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are invoked by
 defining the symbols MJ_OSMESA or MJ_EGL when compiling record.cc. The functions ``initOpenGL`` and ``closeOpenGL``
 create and close the OpenGL context in three different ways depending on which of the above symbols is defined.
 

doc/programming/simulation.rst

@@ -267,7 +267,7 @@ The *physics state* (:ref:`mjSTATE_PHYSICS<mjtState>`) contains the main quantit
 stepping. These are ``mjData.{qpos, qvel, act, history}``:
 
 Position: ``qpos``
-  The configuration in generalized coodinates, denoted in the :ref:`Numerical Integration<geIntegration>` section as
+  The configuration in generalized coordinates, denoted in the :ref:`Numerical Integration<geIntegration>` section as
   :math:`q`.
 
 Velocity: ``qvel``
@@ -322,7 +322,7 @@ Control: ``ctrl``
   Controls are defined by the :ref:`actuator<actuator>` section of the XML. ``mjData.ctrl`` values either produce
   generalized forces directly (stateless actuators), or affect the actuator activations in ``mjData.act``, which then
   produce forces. Note that while all actuators produce forces, the semantics of ``ctrl`` and ``act`` depend on the
-  specifc parameters of the :ref:`actuation model<geActuation>`.
+  specific parameters of the :ref:`actuation model<geActuation>`.
 
 Auxiliary Controls: ``qfrc_applied`` and ``xfrc_applied``
   | ``mjData.qfrc_applied`` are directly applied generalized forces.

doc/programming/visualization.rst

@@ -435,7 +435,7 @@ window buffer size changes whenever the user resizes or maximizes the window. Th
 fixed viewport size. In the code sample :ref:`simulate.cc <saSimulate>` we use a callback which is triggered whenever
 the window size changes, while in :ref:`basic.cc <saBasic>` we simply check the window size every time we render. On
 certain scaled displays (only on OSX it seems) the window size and framebuffer size can be different. So if you are
-getting the size with GLFW functions, use glfwGetFramebuferSize rather than glfwGetWindowSize. On the other hand,
+getting the size with GLFW functions, use glfwGetFramebufferSize rather than glfwGetWindowSize. On the other hand,
 mouse coordinates are returned by the operating system in window rather than framebuffer units; thus the mouse
 interaction functions discussed earlier should use glfwGetWindowSize to obtain the window height needed to normalize
 the mouse displacement data.

doc/python.rst

@@ -922,7 +922,7 @@ custom cameras and lights. The constructor arguments of a ``USDExporter`` instan
 - ``model``: An MjModel instance. The USD exporter reads relevant information from the model including details about
   cameras, lights, textures, and object geometries.
 
-- ``max_geom``: Maximum number of geoms in a scene, required when instatiating the internal .
+- ``max_geom``: Maximum number of geoms in a scene, required when instantiating the internal .
   `mjvScene <https://mujoco.readthedocs.io/en/stable/APIreference/APItypes.html#mjvscene>`__.
 
 - ``output_directory``: Name of the directory under which the exported USD file and all relevant

include/mujoco/mjmodel.h

@@ -161,7 +161,7 @@ typedef enum mjtTextureRole_ {    // role of texture map in rendering
   mjTEXROLE_ROUGHNESS,            // roughness
   mjTEXROLE_METALLIC,             // metallic
   mjTEXROLE_NORMAL,               // normal (bump) map
-  mjTEXROLE_OPACITY,              // transperancy
+  mjTEXROLE_OPACITY,              // opacity
   mjTEXROLE_EMISSIVE,             // light emission
   mjTEXROLE_RGBA,                 // base color, opacity
   mjTEXROLE_ORM,                  // occlusion, roughness, metallic

src/engine/engine_core_constraint.c

@@ -1502,21 +1502,21 @@ void mj_makeImpedance(const mjModel* m, mjData* d) {
         KBIP[4*(i+j)] = 0;
       }
 
-      // standard: K = 1 / (dmax^2 * timeconst^2 * dampratio^2)
+      // standard: K = 1 / (d_width^2 * timeconst^2 * dampratio^2)
       else if (ref[0] > 0)
         KBIP[4*(i+j)] = 1 / mju_max(mjMINVAL, solimp[1]*solimp[1] * ref[0]*ref[0] * ref[1]*ref[1]);
 
-      // direct: K = -solref[0] / dmax^2
+      // direct: K = -solref[0] / d_width^2
       else {
         KBIP[4*(i+j)] = -ref[0] / mju_max(mjMINVAL, solimp[1]*solimp[1]);
       }
 
-      // standard: B = 2 / (dmax*timeconst)
+      // standard: B = 2 / (d_width*timeconst)
       if (ref[1] > 0) {
         KBIP[4*(i+j)+1] = 2 / mju_max(mjMINVAL, solimp[1]*ref[0]);
       }
 
-      // direct: B = -solref[1] / dmax
+      // direct: B = -solref[1] / d_width
       else {
         KBIP[4*(i+j)+1] = -ref[1] / mju_max(mjMINVAL, solimp[1]);
       }