13.1.1 Bad Arguments

Mech functions are written with as much type checking as is possible without restricting the user from incorporating arbitrary mathematical expressions into a model. Unfortunately, this caveat means that there can be essentially no type checking on any symbolic argument that is intended to evaluate to a number.
Many arguments to Mech functions are type checked, such as point and vector arguments, but since point objects and vector objects may also contain symbolic expressions buried in their local coordinates, these items cannot be rigorously type checked until runtime. The following examples show where Mech's type checking catches bad arguments and where others slip through.

This loads the Modeler2D package.

In[1]:=

A Mech body, constraint, or load function is returned unevaluated if it is called with invalid arguments. For example, the Translate2 constraint expects a pair of axis objects that have the head Axis or Line. If Translate2 recognizes that these arguments are incorrect, the entire constraint function is returned unevaluated.

Here is a misspelled axis object.

In[2]:=

Out[2]=

If a constraint function is passed the correct argument types, but the contents of these arguments are invalid, a constraint object is returned with some assumptions made about what to do with the invalid arguments. In the following example, the 3D point specification is not recognized by Modeler2D, so Point[2, {1,0,0}] is replaced with Point[2, {0,0}]. This is certainly not what the user intended, but it causes a valid constraint object to be returned.

Here is a constraint with a 3D local coordinate that should be 2D.

In[3]:=

Out[3]=

The types of errors shown above are diagnosed fairly easily. More elusive problems result when a bad value is given for arguments of type expr. When a Mech usage statement specifies that an argument of type expr is required, it means any expression that will evaluate to a number at runtime may be used. Mathematica has no way of telling in advance whether or not an expression will evaluate to a number, so these arguments cannot be type checked at all.

Here is a constraint with an unchecked expression argument.

In[4]:=

Out[4]=

The last argument to the RelativeDistance1 constraint (2 a) is supposed to evaluate to a number. If, at runtime, the symbol a evaluates to a number, then the constraint is valid. If the symbol a has no definition, or it evaluates to a List or other function at runtime, then Mech will fail. Mathematica has no way of knowing what the symbol a will do at runtime, so it cannot be type checked.
Note that the first argument of a SysCon object is a list of the constraint expressions contained in the object.

Here are the constraint expressions contained in cs.

In[5]:=

Out[5]=