Plots of physical quantities has significantly improved with Maple 2022. The updated useunits option makes unit conversion errors in plots very unlikely. A lot of time is saved when creating plots of physical quantities where values and units must be correct.

One final source of user errors remains: The manual entry of incorrect units in labels.

Below is a way to avoid such errors by computing labels with units for three prevalent axis labeling schemes.

Other desireable labels are given as a suggestion for future plot label enhancements where plot commands could provide formating functionality.

The rendering on this website adds double brakets ⟦ ⟧ wherever units are used. You have to open the document to see how Maple renders.

Simple plot example: Solar irradiance in space (1) (2) This plot has inconsistent axis labeling: •  The vertical axis has units but no name •  The horizontal axis has a name and units but they are not easily distinguishable. Misinterpretation is possible. Due to the close spacing the label could be read as a product of the dimension "time squared" (the time t times hours h is of the dimension time squared). Or the reader confounds name and units. (The use of italic fonts for names and roman fonts for units might not be noticeable and is a convention that is not used everywhere.)   The above labeling should be improved for communication, documentation or publication purposes.   A quick attempt using strings and the options useuints and labels. Axes are now consistent and can be interpreted unambiguously. Formatting can still be improved.   Unfortunately, using the options useunits (for unit conversion) and labels this way introduces a new source of user error when labels are entered with the wrong units.   A way to address this and to ensure unit error-free plotting of expressions of physical quantities is the following:   Step1: Define two lists, one for the units to display and the other for the names to display (3) Step2: Compute labels from the lists This step avoids the labeling error: No manual entry of units in labels required. (4)   Dimensionless labels  Double brackets Parenthesis The axis values equal physical quantities divided by their units. The algebraic equation , for example, is physically speaking correct. Most functions of Maple can process dimensionless expression of the kind  if G is given with appropriate physical units. This way of using physical quantities is consistent with ISO 80000.   Used in Maple to enter units in 2D-Math input mode Can be confounded with functional notation. Units are therefore often written as a whole word (e.g. seconds instead of s).     The time to produce the above three plots was about 10 Minutes. The most part was spent to get the typesetting of the second and third plot correct.   What takes significant more time (more a question of hours when Typesetting is used for the first time) are   Labels with or  formatting.   This formatting might be preferred but is unfortunately again not free from user errors. (I would probably use it if there was a simple and safe way). (5)       Remarks •  For two reasons, I have not given an example with the often used square brackets [ ] because:          Maple uses square brackets already for lists and indexing purposes,     and ISO 80000 uses square brackets as an operator that extracts the unit from a physical quantity (e.g.       ). •  Adding a unit to each value at axes ticks would definitely be a nice labeling feature for simple units. •  Programmatically analyzing the units defined in list  above and converting them in a generic way to a typesetting structure is not possible with a few high-level commands.   •  For inline quotients like in , an additional backslash must be entered in 2D-Math: \/   (6)      This will not prevent evaluation to a normal quotient but the input can be used to create an atomic variable (select with mouse -> 2-D Math -> Atomic Variable) (7)      This makes labeling much easier as compared to typesetting commands (compare to the above statements). (8) In any case it is a good idea to read ?plot,typesetting before experimenting with typesetting.

Axes_with_unit_labels.mw

My personal preference is for dimensionless labels.

Note:

The solution to avoid labeling errors works only for Maple 2022 and higher.

Some plot commands do not support plotting with units, or they do not fully support it yet.

This is an successfull attempt to simulate space frames in MapleSim using the relatively new Rod component.

At t=3s, a lateral force component is applied to make the simulation more interesting.

The structure collapses/folds in an origami style fashion.

To build the model, MapleSim needs additional components.

For example, an equilateral triangle

requires the addition of rigid body frames at the connection of two rods.

Additionally, the rigid body frames must have initial position conditions (ICs) that match the intended structure.

Interestingly the ICs do not have to be set to Treat as Guess. It is only required to put an approximate coordinate. Leaving the ICs on Ignore was sufficient for the attached model.

Rod components can be replaced by Flexible Beam components which require considerably more simulation time and either Revolute joints at their ends or a rather complex connection with Rigid Body frames (of zero length) to adjacent Flexible Beam components.

Spaceframe_2.msim

The pendulum and the cantilever share simple-looking ordinary differential equations (ODEs), but they are challenging to solve:

This post derives solutions from Lawden and Bisshopp by Maple commands, which (to the best of my knowledge) have not been published providing not only results but also the accompanying computer algebra techniques. A tabulated format has been chosen to better highlight similarities and differences.

Both solutions have in common that in a first step, the unknown function is integrated and then in a second step the inverse of the unknown function (i.e., the independent variable) is integrated. Only in combination with a well-chosen set of initial/boundary conditions solutions are possible. This makes these two cases difficult to handle by generic integration methods.

Originally, I was not looking for this insight. I was more interested in an exact solution for nonlinear deformations to benchmark numerical simulation results.  Relatively quickly, I was able to achieve this with the help of this forum, but after that I was left with some nagging questions:

Why does Maple not provide a solution for the pendulum although one exists?

Why isn’t there an explicit solution for the cantilever when there is one for the pendulum?

Why is it so difficult to proof that elliptic expressions are equal?

Repeatedly, whenever there was time, I came back to these questions and got more and more a better understanding of the two problems and the overall context. It also required me to learn more of Maple, and I had to revisit fundamentals of functions, differential equations, and integration, which was entirely possible within Maples help system. Today, I am satisfied to the point that I think it is too much to expect Maple to provide a high-level general integration method for such problems.

I am also satisfied that I was able to combine all my findings scattered across many documents and Mapleprime questions into a single executable textbook-style document with hidden Maple code that:

Exclusively uses and manipulates equation expressions (no assignment operators := were required),

Avoids differentials that are often used in textbooks but (for good reasons) are not supported by Maple,

Exclusively applies high-level commands (i.e. no extraction of subexpression, manipulation
           and subsequent re-assembly of expressions was needed).

The solutions for the pendulum and the cantilever are substantially different although the ODEs and essential derivation steps are similar. I think that an explicit solution for the cantilever, as it exists for the pendulum, is impossible (using elliptic integrals and functions). I leave it open to comments: whether this is correct and whether it is attributable to the set of initial and boundary conditions, the different symmetry of the sine and cosine functions in the ODEs, or both. I hope that the tabular presentation will provide an easy overview, allowing to form an own opinion.

If you are patient enough to work through the table, you will find a link between the cantilever and the pendulum that you are probably not expecting. 

Finally, I have to give credit to Bisshopp, who was probably the first to provide a solution for the cantilever. The clarity and compactness on only 3 pages and the way how the inverse of functions was determined before the age of computers makes this paper worth studying. Also, Lawden has to be mentioned, who did the same on 3 pages for the pendulum in a marvelous book on elliptic functions and applications. It happens that he is overlooked in more recent publications and it’s unclear to me if he was the first who published an explicit solution. His book might be one of the last of its kind in this age of computers, and for that reason alone, it is worth enjoying as he enjoyed writing it.

Download Cantilever_and_pendulum_side_by_side_-_input_hidden.mw

This post discusses a solution for modeling a traveling load on Maplesim's Flexible Beam component and provides an example of a bouncing load.

The idea for the above example came from an attempt to reproduce a model of a mass sliding on a beam from MapleSim's model gallery. However, reproducing it using contact components in combination with the Flexible Beam component turned out to be not straightforward, and this will be discussed in the following.

To simulate a traveling load on the Flexible Beam component, one could apply forces at discrete locations for a certain duration. However, the fidelity of this approach is limited by the number of discrete locations, which must be defined using the Flexible Beam Frame component, as well as the way in which the forces are activated.

One potential solution to address the issue of temporal activation of forces is to attach contact elements (such as Rectangle components) at distinct locations along the beam, which are defined by Flexible Beam Frame components, and make contact using a spherical or toroidal contact element. However, this approach also introduces two new problems:

• An additional bending moment is generated when the load is not applied at the center of the contact element's attachment point, the Flexible Beam Frame component. Depending on the length of the contact element, deformations caused by this moment can be greater than the deformation caused by the force itself when the force is applied at the ends of the contact element. Overall, this unwanted moment makes the simulation unrealistic and must be avoided.
• When the beam bends, a gap (see below) or an overlap is created between adjacent Rectangle components. If there is a gap, the object exerting a force on the beam can fall through it. Overlaps can create differences in dynamic behavior when the radius of curvature of the beam is on the opposite side of the point of contact.

To avoid these problems, the solution presented here uses an intermediate kinematic chain (encircled in yellow below) that redistributes the contact force on the Rectangle component on two support points (ports to attach Flexible Beam Frame components) in a linear fashion.

To address gaps, the contact element (Rectangle) attached to the kinematic chain has the same width as the chain and connects to the adjacent contact elements via multibody frames. In the image below, 10 contact elements are laid on top of a single Flexible Beam component, like a belt made out of tiles. The belt has to be pinned to the flexible beam at one location (highlighted in yellow). The location of this fixed point determines how the flexible beam is loaded by tangential contact forces (friction forces) and should be selected carefully.

Some observations on the attached model:

• Low damping and high initial potential energy of the ball can result in a failed simulation (due to constraint projection failure). Increasing the number of elastic coordinates has a similar effect. Constraint projection can be turned off in the simulation settings to continue simulation.
• The bouncing ball excites several eigenmodes at once, causing the beam to wiggle chaotically in combination with the varying bouncing frequency of the ball. A similar looking effect can also be achieved with special initial conditions, as demonstrated with Maple in this excellent post on Euler beams and partial differential equations.
• Repeated simulations with low damping lead to different results (an indication of chaotic behavior; see three successive simulations below (gold) compared to a saved solution(red)). The moment in the animation when the ball travels backward represents a metastable equilibrium point of the simulation. This makes predictions beyond this point difficult, as the behavior of the system is highly dependent on the model parameters. Whether the reversal is a simulation artifact or can happen in reality remains to be seen. Overall, this example could evolve into a nice experimental fun project for students.

• Setting the gravitational constant for Mars, everything is different. I could not reproduce the fun factor on Earth. A reason more to stay ,-)

Ball_bouncing_on_a_flexible_beam.msim

Transfer functions are normally not used with units. Involving units when deriving transfer functions can help identify unit inconsistencies and reduce the likelihood of unit conversion errors.

Maple is already a great help in not having to do this manually. However, the final step of simplification still requires manual intervention, as shown in this example.

Download Collecting_and_expanding_units.mw