The Schatz Mechanism should move like this

However, with the default solver settings it froze after a few seconds in a planar link configuration. To make it run, I played around with advanced solver settings. Here is one attempt that went nuts:

(More solver settings for strange behavior can be found here: Schatz_Linkage.msim)

Some people might find this amusing. Of course, it is less fun when the initial plan was to spend an hour just for fun with a simple model (an hour is a fair estimate for similar simple looking models in MapleSim). The immediate reaction when seeing such simulation results is to blame the software for being either buggy or incapable. In this case, however, this was not the case, but identifying the root cause was not obvious.

The Schatz mechanism is a so called closed-loop mechanism where the links of the mechanism form a loop (the ground in the model closes the loop). In general, building and modeling mechanisms with loops is less straight forward than thought. Without a-priory knowledge or help (either by documentation or software hints) users can quickly find themselves in a situation of desperate trial and error. What was easy with other models can become a frustrating experience with unsatisfactory outcome. This happened to me on various occasions.   

What makes closed-loop mechanisms more challenging?  After resting for a long time on my virtual pile of unanswered questions, it turned out that the model, on top of being a closed-loop mechanism, is ill-conditioned: The Schatzmechanism is an over-constrained mechanism that is only mobile for certain geometric parameters. MapleSim can simulate such over-constrained mechanisms, but this can be a balancing act for the solver.

Who could have known this? A knowledgeable expert might say that users who do not know what they are doing should not use the software. But how to become aware of over-constrained assemblies when building and running a model in MapleSim does not require to be an expert?  In this case the geometry was taken from a reference that sets the length of the ground link to Ö3. Model build, assembly and simulation instantly worked … but not for an extended time span.

In retrospect, everything is clear. Models that do not assemble do not fit together. Models that freeze in motion “jam numerically”. Linkages and joints of closed-loop mechanisms made of infinite stiff components may not fit together in all geometrical configurations. During runtime, after successful assembly, a stiff model can make a simulation sensitive to numerical errors. This does not mean that the user is dealing with a so-called numerical stiff problem that can be addressed by using stiff solvers. In this case, stiff solvers could not prevent sudden freeze or inversion of movements.

The only remedies that work for infinite stiff and over-constrained mechanisms are the ones that work also in real life. By either introducing mechanical play or elasticity in supports, joints and links, the simulation becomes robust. Numerically, for this case where none of the many advanced solver options made a difference, a simple increase of the relative error in the standard simulation settings worked.  This remedy could be described as introducing more numerical play. Interestingly in a completely different approach of animating a Schatzmechanism @one man also needed to introduce “deformations” in his simulation to make it work.

The Schatzmechanism is of little commercial interest and can therefore be shared. Is it a rare case of successful assembly and freeze during runtime or is it more frequent that users run into similar problems? Only MapleSoft can tell, but in the latter case it could make sense that MapleSim supports the user. I see several possibilities for that:

• A more prominent mention in the documentation that kinematic loops require caution could raise awareness.  
• Algorithmically detecting kinematic loops and informing the user that closed loops can be potentially over-constrained in certain geometric configurations.
• (If possible, analyzing the Jacobian in the frozen configuration might give better hints than solver messages during runtime can provide. The attached model gives the hint with MapleSim 2025.1 that the error tolerance might be too tight, but no indication why.)
• Implementing the mobility formula, analyzing closed loops and issuing a warning when the mobility M is less than 1 (meaning no degree of freedom)

The latter option sounds appealing. However, the degree of freedom calculated by the mobility formula only provides a necessary but unfortunately not a sufficient condition for mobility.  For example, connecting a prismatic joint coaxially to another increases the mobility by one but does not add to the mobility of a mechanism. This means that an advanced algorithm must take the orientation of joints into account to determine the effective degrees of freedom. On the other hand, the Schatzmechanism and some other mechanisms have a mobility of M=0 but can be mobile for certain geometries.

Should Maplesoft implement mobility analysis or are CAD tools that offer some sort of mobility analysis more suitable? In my opinion, from a conceptual point of view, it would be beneficial and faster to have this support already in MapleSim before going into details.

Should the user refrain from modeling infinite stiff mechanisms? I do not think so because they are useful in the context of deriving (analytical) forward and inverse kinematics. Furthermore, there are more mechanisms out there that are mathematically, according to the mobility formula, immobile but useful in daily life. The telescopic fork is a prominet example.

Final note for math enthusiasts:

The Schatzmechanism (invented by Paul Schatz) is a byproduct of the inversion of a cube. Recalling that the diagonal of the unit cube is Ö3 gives a hint of why the Schatz mechanism becomes mobile for this parameter. Also related to the inversion of a cube is the oloid: a solid with a developable surface that touches with its entire surface a flat surface when rolling. The oloid and the Schatz mechanism are closely related, which can be appreciated from this video.

I was wondering whether MapleSoft has opted for an outdated concept. Here is Gemini's answer:

A "better" GUI for Word is subjective, as different users have different needs. The current ribbon interface is great for discovering features, but it can also feel cluttered.

With the former GUI (having a larger quick acess bar) and a tool bar (in red)

only one click was required with substantially less mouse movement.

Personally I would switch to the new GUI with the following improvements

• a quick access bar that is customizable
• a smart ribbon that switches to the edit mode tab when the cursor is placed on editable text or a new text/input/document block is inserted

Having the functions that I use most frequently available in the quick access tool bar (highlighted in yellow) would allow me to minimize the ribbon with the same productivity and even more screen space as before.

Keyboard shortcuts that differ from standard OS shortcuts are not a viable alternative for me.

Overall, the direction with the new ribbon seems to be right to get new users productive faster. It seems to be a good choice without clear alternatives, and its graphical design aligns much better with the core values Maple provides.

However, becoming productive fast does not mean that the productivity is high. From this perspective the former GUI is not outdated yet. The workflow with it is much faster and more focussed on math and code.

Perhaps MapleSoft has solutions that will make the new GUI even more productive than the former GUI. This would be great!

For a long time, triggered by a disagreement with one of my teachers, I wanted to demonstrate that Euler equations are not absolutely necessary to reproduce gyroscopic effects. Back then, there were no computer tools like Maple or programming languages with powerful libraries like Python. Propper calculations by hand (combining Newton’s equations and vector calculus) would have required days without guarantee of immediate success. Overall, costs and risks were too high to go into an academic argument with someone in charge of grading students.

Some years ago, I remembered the unfinished discussion with my teacher and simulated with MapleSim the simple gyroscope with two point masses that I had in mind at the time. It took only 10 minutes to demonstrate that I was right. At least I thought so. As I discovered recently when investigating the intermediate axis theorem, MapleSim derives behind the scenes Euler equations. This devalued the demonstration.

This post is about a second and successful attempt of a demonstration with Maple employing Lagrangian mechanics.  A rotating system of three point masses connected by rigid struts is used. The animation below from the attached Maple worksheet exactly reproduces a simulation of an equivalent T-shaped structure of three identical masses presented here.

Lagrangian Mechanics

The worksheet uses Lagrangian mechanics to derive equations of motion. Only translational energy terms are used in the Lagrangian to prevent Euler equations from being derived. To account for the bound motion of the three point masses, geometric constraints with Lagrange multipliers were added to the Lagrangian L of the system. This lead to a modified Lagrangian L’ that can be used with dedicated Maple commands to derive with little effort a set of Lagrange’s equations of the first kind and the corresponding constraints

(source https://en.wikipedia.org/wiki/Lagrangian_mechanics)

For the system of three point masses the above equations lead to 9 coupled second-order ordinary differential equations (ODEs) and 3 algebraic constraints 

(Maple output from the command Physics,LagrangeEquations)

where x_i, y_i and z_i are the components of the position vectors _i of the masses 1 to 3 and the l_i,j are the constraints between the masses i and j, and b and h are the base and the height of the triangle.

The 12 equations together are also referred to as differential algebraic equations (DAEs). Maple has dedicated solvers for such systems which make implementation easy. The most difficult part is setting the initial conditions for all point masses. In this respect MapleSim is even easier to use since not all initial conditions have to be exactly defined by the user. MapleSim also detects constraints that allow for a simplification of the problem by reducing the number of variables to solve. This leads automatically to 3 instead of 12 equations to be solved. Computational effort is reduced in this way significantly.

Newtonian Mechanics

One could argue now that the above is a demonstration with Lagrangian mechanics and not with Newtonian mechanics. To treat the system in a Newtonian way, the masses must be isolated and internal forces acting on each mass via the struts are applied to each mass and effectively become external forces. This leads to 9 ODEs with 27 unknows

Following actio=reactio for each of the (massless) struts reduces the number of unknows to 18

To solve for the 18 unknows, 9 more relations are required. 3 algebraic constraints that keep the distance between the masses constant have already been listed in the previous section. 6 further algebraic constraints can be established from the fact that the force vectors point towards the opposing mass (see also below).
The effort to solve this system of equations will be even greater but with the benefit of having information about the internal forces in the system. Before making this effort, it is advisable to take a closer look at the equations of motion derived so far.

Forces and the "mysterious" Lagrange Multipliers

Rearranging equations of motion from Lagrangian mechanics to

and comparing this to the equations of motion from Newtonian mechanics yields in vector notation 

or more general for the forces

where the _i are the position vectors of the individual masses and the  are the constraint forces between them.  

In the case of a triangle formed by struts all internal forces must act in the direction of the edges of the triangle. If they would not act this way, opposing pairs of  and   would create a torque around the struts which would lead to an infinite angular acceleration of the massless struts. The above equation confirms this reasoning: The internal forces act in the direction of the difference vectors between the position vectors of the masses (which describe the edges) and scale with l_ij.

The beauty of the Lagrange multipliers in this case is that they hit 3 birds (three components of the vectors ) with one stone. This reduces the number of unknowns.

However, the Lagrange multipliers are somehow mysterious because they do not represent a physical quantity, but they can be used to calculate meaningful and correct physical results.

What makes them even more mysterious is the fact that positions constraints can be expressed in different ways. In the above example the square of the distance between the masses is kept constant instead of the distance. There are many more possibilities to formulate the constraint of constant distance and each of them results in different multipliers l_ij with different units. In principle they should all work equivalently but might not all be usable with dedicated solvers.

According to the above equation, the internal forces in a strut scale with the Lagrange multipliers and the length of the strut. During the back and forth flip of the triangle in the above animation the forces vary which can be appreciated from the l_ij in the following plot. 

Some observations:

• At the start, only the strut between the red and the green masses is tensed by centrifugal forces. This would have been intuitively expected.
• At the start, the broken symmetry in the initial conditions is already visible by the imbalance of the forces in the two other struts.
• At no time two forces are zero
• There is never compression in two struts at the same time. The existence of compression forces renders any attempt to replace the struts by cables useless
• Plotted together in 3D the Lagrange multipliers describe a seemingly perfect circle.

The last observation in particular shows that both the Lagrange multipliers and the IAT still hold some secrets that need to be clarified:

• Is it an exact circle? How to prove that?
• Does a circle appear for all initial conditions and geometries (obtuse isosceles triangles) when the intermediate axis theorem manifests?
• What does the circle represent? Is it a kind of an invariant between the Lagrange multipliers that allows the calculation of one force when the two others are known?
• Is there an analytical representation of the circle as a function of the geometry and the initial conditions?
• What determines the center, the radius and the orientation of the circle?

Conclusion

Overall, the approach of adding non-physical terms that are zero to a physical quantity (the difference between kinetic and potential energy) to derive something meaningful is not obvious at all and underlines the genius of Lagrange. For a system of three bound masses it could be used to calculate internal forces as opposed to the more common use of calculating external constraint forces. Beyond the lack of fully satisfying intuitive explanations, the IAT still offers unanswered scientific questions.

PS.: 

• The exercise was a nice cross-check of MapleSim and Maple.
• dsolve and odeplot are awsome

IAT_without_Euler_equations.mw

Just an observation.

I was wondering if less obvious errors than in the below can be avoided with future versions of the AI assistant. Maybe a warning that a formula uses special Maple symbols is possible.

Formulas without dimensions are more susceptible to undetected errors.

Download AI_formula_assistant.mw

P.S.:

This is a real example that happend to me where I did not notice the minus sign in Maples output in equation (1). The error  can easily be fixed by adding "local I" as the first statement of the document and the deflection becomes 1 mm.

MaplePrimes offers spell check and correction

for the function "Contact Author"

Suggestion:
For the sake of message clarity (and to save time) it would be desireable to have spell checking and correction in other MaplePrimes message bodies of as well.