BuildMech
2D/3D• BuildMech[level] is used to force a build of the mechanism equations to the specified level at any time.
• BuildMech is also an option for SetConstraints and SetLoads. BuildMech -> level specifies what parts of the mechanism model are built immediately.
• level can be None, All, Location, Velocity, Acceleration, Static, Kinematic, or Dynamic.
• BuildMech[Clear] clears all equations in the current model and releases their memory. • BuildMech[Clear] marks all parts of the current model so that they will be rebuilt the next time they are used, but nothing is rebuilt immediately.
• BuildMech[None] does nothing.
• BuildMech may also be called with Constraints, Jacobian, VelocityTerms, AccelerationTerms, Loads, Centrifugal, or MassMatrix as its argument to clear and rebuild the specified part of the model.
• The default settings for BuildMech with SetConstraints and SetLoads are Location and Static, respectively. BuildMech can be used to force all of the system equations to be built before all of the user variables in the system have been defined.
• If the user introduces variables into the model that are not explicitly symbols (such as c[1], c[2], ...) they will not be identified by Mech and the delayed equation building that occurs when velocity or acceleration solutions are requested will fail. In such cases, specifying BuildMech->Dynamic will cause all of the system equations to be built immediately.
• See also: CheckSystem, ClearMech. Further Examples Load the Modeler2D package. Consider the following sequence. First we build a model with one symbolic constant  . At the time the constraint expressions and Jacobian are formed, the constant is undefined so it remains a symbolic part of the constraints and Jacobian, which are built immediately. If we then define the constant and ask for a Velocity solution, the velocity terms are immediately derived from the constraint expressions during the execution of SolveMech, so we might expect that changing the value of after calling SolveMech once would have no further effect.
Out[5]= |  |
Out[7]= |  |
Noting the change in the returned value of  2d, changing the value of after building the velocity terms clearly does have the desired effect. This is because SetConstraints took note of the presence of undefined symbols in the original constraint expressions and ensured that they remained symbolic during the subsequent building of other dependent expressions. This can be seen by directly inspecting the velocity terms.
Out[9]= |  |
However, if we replace the symbol with the expression a[1], SetConstraints fails to recognize it as a variable and we get different results.
Out[13]= |  |
Out[15]= |  |
This time the change in the value of a[1] has failed to affect the operation of SolveMech.
There are two ways we can address the problem. We can immediately force the velocity terms to be rebuilt. This is a poor choice because the new value of a[1] again becomes embedded in the velocity terms and thus another change to a[1] fails to have the desired effect.
Out[17]= |  |
Out[19]= |  |
Out[21]= |  |
A better answer is to force a complete rebuild of all system equations while a[1] is known to be undefined, thus ensuring that all future changes to a[1] will have the desired affect.
Out[24]= |  |
Out[26]= |  |
Out[28]= |  |
Another entirely equivalent solution would be to give the BuildMech->All option to SetConstraints. This would build all needed expressions immediately, leaving no opportunity for the value of a[1] to become embedded.
| 
