672 Reputation

17 Badges

3 years, 16 days

MaplePrimes Activity

These are Posts that have been published by C_R

Although not mentioned in the documentation, the flexible beam component of MapleSim allows for simulation of large deflections.  

In the animation, a flexible beam is loaded with a moment (red arrow) at its free end. Assuming an Euler-Bernoulli beam and slow loading (i.e., no dynamic forces), the beam should deform to an arc of constant radiusNot only the deformation of the beam can be described analytically, also the path (red trace) of the free end follows an analytical curve.


I used this test case to get a better understanding of nonlinearities observed in an oscillating system using flexible beams (https://www.mapleprimes.com/posts/215718-Mode-Coupling-With-Flexible-Beams-). The system required tuning of the structure to develop mode coupling. This could not be explained by linear theory. It was unclear whether the large deflections (nonlinear kinematics of the beam) themselves or the implementation of the flexible beam component were responsible for that.  


What I have learned so far with the test case using only default settings: 

  • For moderate deflections there is no difference to textbook formulas.
  • Up to 15 degrees rotation of the end frame, the difference between observed displacement and the Bernoulli beam stays bellow 5%.  
  • Up to 30 degrees rotation of the end frame (as in the mode coupling example) the trace of the end frame conforms well with the analytical path.
  • To simulate very large deflections beyond 45 degrees rotation, the beam needs to be segmented to closely follow the analytical path.  

For those that are unsure about the fidelity of their models, I can suggest increasing the numbers of flexible beam components and to compare. I did this in the case of the mode coupling example and noticed no difference. So, the component was not responsible for the nonlinearities. It were the kinematics.

It's unclear whether this good performance in large deflections was intended or is a byproduct of the sophisticated multibody dynamics under the hood.  Maybe an expert can tell more.

Overall, to what I have seen the (static) performance was very satisfying. Judging dynamic performance is much more difficult. Has anyone experience to share with that?




is what I have used.


As a student I came across an amazing lab experimentA T-type structure with two masses attached to it showed a sudden change in oscillation mode.  


With MapleSim I was able to reproduce the experiment.

At the time I was told that this perplexing phenome happens because there are always imperfections. 


Today we would probably say that the symmetry has to be broken. The attached example has two parameter sets that a) break symmetry of boundary conditions and b) by structural asymmetry (i.e imperfection). Asymmetry in the initial conditions should also be possible (but I could make work with flexible beams). 

Compared to coupled oscillators that exchange energy via a coupling spring, this example exchanges energy via masses. In fact in its simplest implementation only one mass and two elastic structures are required for this type of mode coupling. MapleSim multibody library offers plenty of possibilities to demonstrate thisFlexible beams are not required. However, flexible beams show mode coupling beautifully and allow a simple reproduction in real life. For that the worksheet contains a parameter set to build a real model with steel wires. Tuning by adjusting the length of the vertical post is required since nonlinearities already shift frequencies in the model. 


I would be interested in other cool examples of mode coupling. I am also interested in solutions for flexible beams that impose asymmetry in the initial conditions. To keep it realistic at the start, the T should be bend as one would bend it with a fingertip in x direction. It would be even more realistic if the arms are flexed by gravity with zero velocity at the start of the simulation. How can this be done? 



In the context of analyzing physical systems I often have to plot results in the form of y=f(x,a,b,c,…). Here the plot variables x and y are physical quantities and the system parameters a,b,c… can have units as well.

After substitution of parameters the expression f(x,a,b,c,…) can be plotted using plot(f(x,a,b,c,…),x_range). Unit choice and labeling of the abscissa work already well when x_range is given in the format x=x0..x1 (where x0 and x1 have a value and a unit). This is already a huge improvement since labeling and unit conversion errors on the abscissa are almost impossible.

Also, the units on the ordinate are correctly displayed. However, if the depended variable y is desired to be displayed on the ordinate it must be added by hand using the label option. In doing so the display units and labels of both axes must be re-entered by hand. This re-entering step is a source of labeling and conversion errors.

To improve ordinate labeling and to reduce conversion errors I would love to see two improvements:

  • A plot option that would allow unit conversion of plot axes. I.e. telling Maple in which units a physical quantity has to be displayed and forcing a rescaling of the values of the physical quantities.
  • With less priority and additional to expressions, the plot command should also accept equations in the form of y=f(x) as input. This would lead to a very compact syntax that produces content rich and, more importantly, correct plots of physical quantities. Wrong labeling and conversion errors would be very unlikely.

Overall, I am very pleased by Maples unit functionality. I have been reluctant to switch from my old work style of using names as unit placeholder and self-made conversion sets. But now I feel that the likelihood of producing unit conversion errors with my old work style has become higher than using Maples units.

I can only encourage interested users to give units a try. Its good!  For me it has turned out to be time worth invested.

I also hope that Maplesoft continues their efforts of providing more unit functionalities. It’s a big task but calculations with physical quantities are also a big differentiator.  

Equation labels are great!

I use them extensively to produce textbook style documentation that is understandable for non-Maple users. Even if Maple input is not hidden, documents look much cleaner since auxiliary names and the assignment statement “:=” do not have to be used most of the time.

Suggestions to improve Maple 2021 equation label functionality (in order of preference):

  • In a text passage or Maple input: Double click on a label reference to open the insert label dialogue (crtl-L) in order to change the reference (instead of deleting the reference and inserting a new reference).
  • Right click on an equation label to hide it with the context menu. Or right click on the output and have a “show/hide label" option.
  • After a document is finished, input is hidden and before printout/export is produced: A function that hides/shows all labels that are not referenced in text passages.
  • A search function for equation labels in a document, or alternatively: a pallet simliar to the variable pallet to manage labels.
  • Labels inside a text passage that refer to executable math with toggled input. This would allow the definition of expressions inside a text passage and use them in subsequent calculations. Example for a text passage: “If we insert for the mass m=15 kg in equation (33), the frequency response looks as follows:" plot(subs(label_of(whatever has been attributed to m=15kg),(33)),plot_range). This would reduce redundant entries in the document and potential mismatch between text and calculation results.
  • Renaming of single labels (i.e. assigning an alias) either by right click on the label or by a pallet.
  • Labels for non-executable math inside a text passage for further use in other text passages or later insertion in executable math.


  • There is another (not documented?) feature that is very handy: Double click on an equation label inserts the equation label at the cursor position. A nice time saver.
  • Only recently I found out that single equation labels can be hidden/removed using Format>Equation Labels>Selection. Since this option was always grayed out, I could not make sense out of it, because the text was not self-explanatory to me.  Instead of Format>Equation Labels>Selection a more self-explaining menu entry would be desirable. “show/hide selection” would already better describe the action behind the menu item. However, it is still not intuitive to select output in order to make equation labels disappear (that are by the way not highlighted in blue by the selection process when only a single output/execution group is selected). There are many reasons that could make a change to self-explaning menu items not that straight forward as it sounds. In this case a mouse-over is always helpful to get more explanations on a button or a menu item. Alternatively and probably better: It would be more straight forward to select or click onto labels to manipulate them. This of course only works for one label at the time, which in my case is the most common use case.
  • Equation labels are unique. They enable a work and documenting style that other math tools do not provide. If used consistently, they provide a new level of abstraction where explanatory text and computation can be combined in way that a mathematical interpreter (human or a smart machine) could proof results using only textbook style documents as input (e.g. pdf scans). At least, this is theoretically possible. However, I have noticed that many examples from users do not make use of equation labels. They are still pretty much done in a traditional programming style where loads of unnecessary variables are used. This is understandable since many people start mathematical problem solving with the aid of computers by programming. So new users to Maple use Maple pretty much the same way they were trained.
  • I am fully aware that there are many applications where equation labels are not the most efficient way of producing a result. But producing a result is different from documenting results or even documenting a mathematical proof.


1 2 Page 2 of 2