ArtiSynth is primarily “unitless”, in the sense that it does not define default units for the fundamental physical quantities of time, length, and mass. Although time is generally understood to be in seconds, and often declared as such in method arguments and return values, there is no hard requirement that it be interpreted as seconds. There are no assumptions at all regarding length and mass. Some components may have default parameter values that reflect a particular choice of units, such as MechModel’s default gravity value of , which is associated with the MKS system, but these values can always be overridden by the application.
Nevertheless, it is important, and up to the application developer to ensure, that units be consistent. For example, if one decides to switch length units from meters to centimeters (a common choice), then all units involving length will have to be scaled appropriately. For example, density, whose fundamental units are , where is mass and is distance, needs to be scaled by , or , when converting from meters to centimeters.
Table 4.1 lists a number of common physical quantities used in ArtiSynth, along with their associated fundamental units.
|torque||same as energy (somewhat counter intuitive)|
|Poisson’s ratio||1||no units; it is a ratio|
|rotary stiffness||same as torque|
|mass damping||used in FemModel|
|stiffness damping||used in FemModel|
For convenience, many ArtiSynth components, including MechModel, implement the interface ScalableUnits, which provides the following methods for scaling mass and distance units:
A call to one of these methods should cause all physical quantities within the component (and its descendants) to be scaled as required by the fundamental unit relationships as shown in Table 4.1.
Converting a MechModel from meters to centimeters can therefore be easily done by calling
As an example, adding the following code to the end of the build() method in RigidBodySpring (Section 3.2.2)
will scale the distance units by 100 and print the values of various quantities before and after scaling. The resulting output is:
It is important not to confuse scaling units with scaling the actual geometry or mass. Scaling units should change all physical quantities so that the simulated behavior of the model remains unchanged. If the distance-scaled version of RigidBodySpring shown above is run, it should behave exactly the same as the non-scaled version.