C_R

3427 Reputation

21 Badges

5 years, 325 days

MaplePrimes Activity


These are Posts that have been published by C_R

As an enthusiast and frequent user of unit functionalities, I would like to suggest some improvements.

Example 1: 

Assume a quantity equation w = f(z) where we substitute z = 100*`μm` (and probably other parameters with units) to obtain a numerical result.
After some simplifications the result is

w = 0.3365290139e-4*Unit('m')

w = 0.3365290139e-4*Units:-Unit(m)

(1)

 

A result in this form is the most frequent physical quantity equation with units in use:

A physical quantity denoted by the name w that is equal to a numerical value times a physical unit.

In this form it is also the shortest way to define/name scientific constants, scientific and engineering parameters, and results for variables/unknowns.  


To better interpret the above result a conversion to micron is desirable. This unfortunately does not work with the context panel. Alternatively one could think of mapping a command onto the equation.
(Mapping a command is a good practice to threat the left-hand side and the right-hand side of an equation equally.)

map(convert, w = 0.3365290139e-4*Units:-Unit(m), units, micron)

Error, (in convert/units) unable to convert `1` to `micron`

 

This however does not work, since the left-hand side does not contain the dimension length, but only the name w of the physical quantity.  

A way to convert is:

lhs(w = 0.3365290139e-4*Units:-Unit(m)) = convert(rhs(w = 0.3365290139e-4*Units:-Unit(m)), units, micron)

w = 33.65290139*Units:-Unit(micron)

(2)

For a single result this might be acceptable, but for a list of results this not practical.

In any case not being capable to apply to an equation the same operation to both sides bares the risks of introducing errors.

NULL

Example 2: 

More complicated are results of this kind

NULL

w((1/10000)*Unit('m')) = 0.3365290139e-4*Unit('m')

w((1/10000)*Units:-Unit(m)) = 0.3365290139e-4*Units:-Unit(m)

(3)

A way to convert this to w(100*`μm`) = 33.65290139*`μm`:

w(convert(op(lhs(w((1/10000)*Units:-Unit(m)) = 0.3365290139e-4*Units:-Unit(m))), units, micron)) = convert(rhs(w((1/10000)*Units:-Unit(m)) = 0.3365290139e-4*Units:-Unit(m)), units, micron)

w(100*Units:-Unit(micron)) = 33.65290139*Units:-Unit(micron)

(4)

This is too complicated.

Instead, eval with a manually entered conversion can be used for this

eval(w(100*Units:-Unit(micron)) = 33.65290139*Units:-Unit(micron), Unit('m') = 10^6*Unit('`μm`'))

w(100*Units:-Unit(micron)) = 33.65290139*Units:-Unit(micron)

(5)

However, this is old style: The way we had to work before the introduction of the unit package.

 

In other areas Maples unit conversion functionalities are more advanced.

Plotting with units for example has been improved to the point where unit conversion errors of quantity expressions are almost impossible (in contrast to numerical-value expressions): The user can specify the units to display and the numerical values of the physical quantities are converted accordingly.

 

S1: To catch up with that improvement, conversion of the results as in Example 1 in the form of quantity equations would be desirable as well.

 

Other desirable unit conversions of quantity expressions are

 

• 

S2: Right click (or select and right click) a unit in Maple output and conversion to a new unit with the context panel (try it with one of the above outputs: nothing happens).

• 

S3: Replacement of a unit by a desired unit of the same dimension (Example 2).

• 

S4: Replacement of a unit by conversion to a new equivalent unit (e.g.: "⟦(m kg)/(s^3 A)⟧ to V/(m)") matching the pattern of the unit but not necessarily the pattern of the underlying Unit commands (for this subs can be used already).

 

For all suggestions, it is important that the physical quantity to be converted does not change, i.e. if a unit is changed, the numerical value of the physical quantity is changed accordingly.

 

Download Unit_conversion_in_quantity_expressions.mw

This post is about the visualization of a gyroscopic phenomenon of a rotating body. MapleSim models and a description for those who do not have MapleSim are provided for their own analysis. Implementation with other tools like Maple might give further insight into the phenomenon.

With appropriate initial conditions, a ball thrown into a tube can pop out of the tube. This can be reproduced with a MapleSim model

Throwing_a_ball_into_a_tube_A.msim

To hit a perfect shot without trial and error, time reversal was applied for the model (reversed calculation results of a ball exiting the tube are used as initial conditions for the shot). This worked straight away and shows that this model is sufficiently conservative.

This phenomenon has recently attracted attention on YouTube. For example, Steve Mold demonstrates the effect and provides an intuitive explanation which he considers incomplete because the resulting vertical oscillation of the ball does not match theory and his experiments. He suspects that the assumption of a constant axis of rotation of the ball is responsible for this discrepancy.

However, he cannot demonstrate a change of the axis of rotation. In general, the visualization of the rotation axis of a ball is difficult to achieve in an experiment. On the contrary, visualization is much easier in a simulation experiment with this model:

Throwing_a_ball_into_a_tube_B.msim

The following can be observed for a trajectroy that does not exit the tube:

At the apex (the top) of the trajectory, the vector of rotation (red bold in the following images) points downwards and is essentially parallel to the axis of the cylinder. The graph to the left shows the vertical (in green) position and one horizontal position (in red). The model applies gravity in negative y direction.

Ein Bild, das Text, Diagramm, Screenshot, Reihe enthält.

Automatisch generierte Beschreibung 

On the way down, the axis of rotation points away from the direction of travel (the ball orbits counterclockwise in the top view).

Ein Bild, das Text, Diagramm, Screenshot, Reihe enthält.

Automatisch generierte Beschreibung

At the bottom, the vector of rotation points towards the axis of the cylinder.

Ein Bild, das Text, Diagramm, Screenshot, Reihe enthält.

Automatisch generierte Beschreibung

On the way up, the axis of rotation points in the direction of travel.

Ein Bild, das Text, Diagramm, Screenshot, Reihe enthält.

Automatisch generierte Beschreibung

These observations confirm that the assumption of a constant axis of rotation is too simplified. Effectively the ball performs a precession movement know from gyroscopes. More specifically, the precession movement of the rotation axis rotates in the opposite direction of the rotation of the ball.

However, the knowledge and the visualization of this precession movement do not provide more insight for a better intuitive explanation of the effect. As the ball acts like a gyroscope, a second attempt is to visualize forces that perturb the motion of the ball. Besides gravity, there are contact forces exerted by the tube. The normal force at the contact as well as the gravitational force cannot generate a perturbing momentum since they point to the center of the ball. Only frictional forces at the contact can cause a perturbing momentum.

Contrary to the visualization of the axis of rotation, visualization of contact forces is not straight forward in MapleSim, because neither the contact point nor the contact forces are directly provided by components of the MapleSim library. Only for a single contact point, a work-around is possible by measuring the reactive forces on the tube and then displaying these forces in a moving reference frame at the contact point. The location and the orientation of this frame are calculated with built-in mathematical components. To illustrate the additional effort, the image below highlights in yellow the components only needed for the visualization of the above images, all other components were required to visualize the contact forces and frictional moments.
Ein Bild, das Text, Diagramm, Plan, parallel enthält.

Automatisch generierte Beschreibung
Throwing_a_ball_into_a_tube_C3.msim
It required many attempts to get to a working model. Several kinematic models for a rotating reference frame at the contact point failed. Finally, mathematical operations on kinematic signals (measured by sensors) and motion drivers were successful.  

In the following, the model is used to visualize the right-hand rule for the following vectors:

  • in green the disturbing frictional moment
  • in red (now with a double headed arrow) the angular velocity (for a sphere it points in the same direction as the vector of the angular momentum and the axis of rotation)
  • in pink the vector of the angular velocity of the precession movement

At the top, the vector of precession indicates that the axis of rotation is diverted away from the direction of travel (i.e. pointing backwards). This is in line with the above image of the ball “on the way down”.

Ein Bild, das Screenshot, Text, Diagramm, Reihe enthält.

Automatisch generierte Beschreibung

At the bottom, the vector of precession indicates also that the axis of rotation is diverted away from the direction of travel. This however cannot be seen in the above image of the ball “on the way up”. This discrepancy is an indication that the vector of angular velocity of the precession movement might not sufficiently predict the future orientation of the axis of rotation.

Overall, there is little symmetry in the two extreme positions at the top and at the bottom. A bending of the trajectory downwards (pitching down) at the top indicated by the vector of precession, cannot be seen at the bottom: The vector of precession does not indicate a bending of the trajectory in an upward direction.

It turns out that the right-hand rule does not provide the hoped-for better explanation either. However, the model was not a complete waste of time since it provided two unexpected and very counterintuitive observations:

  • At the bottom, the speed of the balls center is the lowest. For an object descending in a gravitational field, one would expect a gain in speed. A closer look at the graph of the angular velocity (lower graph) reveals that the ball is spinning at the highest rate at the bottom. This means that potential and kinetic energy at the top are converted to rotational energy at the bottom.
  • Although the ball slows down (and speeds up in angular velocity) while descending there is no frictional force component in circumferential direction. Seen from above, the ball orbits at constant velocity. Only a vertical frictional force component acts all the time. Frictional forces in circumferential direction slowing down the ball can only be seen at the beginning of the simulation when the ball slips on the tube up to the moment when it rolls without slippage.

Overall, the closer one looks, the less intuitive it gets. What makes this phenomenon so difficult to understand is the constantly changing constraint of the ball. At each time increment the location and orientation of the contact changes with respect to the direction of the (instantaneous) direction of precession. This makes the phenomenon so obscure. It might be easier to find an “intuitive” explanation for the tennis racket paradox (or intermediate axis theorem) where no external forces act.

Even with a physics background and the right-hand rule of precession at hand, it requires allot of imagination to predict the movement of the ball. This is, in my opinion, not intuitive at all for most people. After all, the premotor cortex of the human brain seems to have constant difficulties to learn precession – for sure precession prediction is not hardwired. If it was, the paradox wasn’t so perplexing, and we could imagine/predict what the golf ball does next.

In summary, this simulation experiment revealed details not known before (at least to me) about the phenomenon. The experiment did not provide more insight for a better intuitive explanation but on the contrary raised more questions. It is another case of “knowing more, but not getting smarter”.

At the very least, the simulations also show the benefits of carrying out virtual experiments under various conditions that are difficult or even impossible in an experiment. In any case, such experiments are of educational value  - not only in classical physics.

 

Comments on the product:

It was possible to verify results of MapleSim: The model reproduces the magic numbers sqrt(7/2) and sqrt(5/2) for the ratios of circular rotation and vertical oscillation frequencies for a full and a hollow sphere respectively. See the first model.

The (laborious) work-around presented here cannot be applied to most real-world contact problems. Visualization of the contact point, contact forces and contact slippage are therefore a desirable extension to MapleSim’s contact capabilities. I do not think that this is provided by other tools.

A surface pattern for the ball would have been helpful to better visualize the rotation of the ball.

A moving observer view (in this case an observer in the reference frame of the contact) could facilitate observation.

Further viewing:

  • The physical engine of Blender was used in a video to reproduce the phenomenon qualitatively.
  • There is an ”improved” intuitive explanation of Steve Mold’s explanation which uses frictional forces and provides physical background. It is not clear to me which part of the visualization is animated and which is physically simulated. At least some sequences do not make sense: The vector of the external frictional moment on the ball suddenly changes direction. The “improved” intuitive explanation also states that the rotational axis leans constantly toward the contact point. I do not see this in my simulation (the contact point is indicated with a red dot in the images above). Also, the precession vectors in my simulation did not reveal an intuitive explanation for a reduction in vertical oscillation frequency.

Further work:

  • Is the vertical oscillation truly sinusoidal as the horizontals are?
  • Is the point of contact always in the northern hemisphere of the ball? More general: In one hemisphere?
  • In a simulation without gravity: Does the vector of precession better predict the trajectory?
  • ...
     

From a discussion about expanding unit expressions with compound units I concluded that expanding derived units such as Newton, Watt, Volt, Tesla,... to SI base units is difficult in Maple.

Unintentionally, I came across a rather simple solution for SI units.

toSIbu := x -> x = Units:-Unit(simplify(x/Unit('kg'))*Unit('kg'));

converts derived SI units to SI base units. It’s the inverse of what the units packages and simplify do (i.e. simplification to derived units).

What makes it maybe more interesting: It also works, again unintentionally, on other units than SI units. If, one day, you come along an erg or a hartree or or a kyne and you cannot guess the SI units convert/units needs, try

toSIbu(Unit('pound'));
toSIbu(Unit('hp'));
toSIbu(Unit('electron'));
toSIbu(Unit('hartree'));
toSIbu(Unit('bohr'));
toSIbu(Unit('barye'));
toSIbu(Unit('kyne'));
toSIbu(Unit('erg'));
toSIbu(Unit(mile/gal(petroleum)));

Maybe handy one day when you do not trust AI or the web.


 

NULL 

toSIbu := x -> x = Units:-Unit(simplify(x/Unit('kg'))*Unit('kg')):
toSIbu(Unit('N'));
toSIbu(Unit('J'));
toSIbu(Unit('W'));
toSIbu(Unit('Pa'));
toSIbu(Unit('C'));
toSIbu(Unit('F'));
toSIbu(Unit('S'));
toSIbu(Unit('H'));
toSIbu(Unit('T'));
toSIbu(Unit('V'));
toSIbu(Unit('Wb'));
toSIbu(Unit('Omega'));
toSIbu(Unit('lx'));
toSIbu(Unit('lm'));
toSIbu(Unit('degC'));
toSIbu(Unit('rad'));
toSIbu(Unit('sr'));

Units:-Unit(N) = Units:-Unit(m*kg/s^2)

 

Units:-Unit(J) = Units:-Unit(m^2*kg/s^2)

 

Units:-Unit(W) = Units:-Unit(m^2*kg/s^3)

 

Units:-Unit(Pa) = Units:-Unit(kg/(m*s^2))

 

Units:-Unit(C) = Units:-Unit(A*s)

 

Units:-Unit(F) = Units:-Unit(A^2*s^4/(m^2*kg))

 

Units:-Unit(S) = Units:-Unit(A^2*s^3/(m^2*kg))

 

Units:-Unit(H) = Units:-Unit(m^2*kg/(A^2*s^2))

 

Units:-Unit(T) = Units:-Unit(kg/(A*s^2))

 

Units:-Unit(V) = Units:-Unit(m^2*kg/(A*s^3))

 

Units:-Unit(Wb) = Units:-Unit(m^2*kg/(A*s^2))

 

Units:-Unit(`Ω`) = Units:-Unit(m^2*kg/(A^2*s^3))

 

Units:-Unit(lx) = Units:-Unit(cd/m^2)

 

Units:-Unit(lm) = Units:-Unit(cd)

 

Units:-Unit(`°C`) = Units:-Unit(K)

 

Units:-Unit(rad) = Units:-Unit(m/m(radius))

 

Units:-Unit(sr) = Units:-Unit(m^2/m(radius)^2)

(1)

NULL


 

Download toSIbu.mw


(All done with Maple 2024 without loading any package)

 

 

 

This post summarizes links for those who have not studied numerical integration methods from scratch and are interested in simulation settings in MapleSim (like me).

The MapleSim help pages simulation settings and advanced simulation settings give first guidance for the trained user but do not provide explanations or links for the terms used in the description of the settings (as for example: stiffness, constraint stabilization, constraint projection, events and event iteration,...).

It can easily be overlooked that Maple help pages provide further information for most of the terms. Under the assumption that MapleSim uses the same terminology as Maple, I recommend to first have a look at Maple help topics before consulting the web or other resources. Since searching and retrieving can be time consuming, I made a list of helpful links.

There are still some open points. I would be happy for more links and help in filling these gaps.

 

How Maple simulates

?MapleSimUserGuide,Chapter04:
section 4.1 How MapleSim Simulates a Model

?tasks,generatingCode

Ein Bild, das Text, Screenshot, Diagramm, Design enthält.

Automatisch generierte Beschreibung

 

Solvers

An overview of solvers: ?dsolve,numeric

Differential Algebraic Equation introduction: ?MaplePortal,DAE

Overview of numeric differential-algebraic equation solvers (index reduction, constraint drift, projection):
 ?examples/numeric_DAE and ?dsolve,numeric,DAE_extension

Stiffness and stiff solvers

Stiffness and stiff IVPs: ?dsolve,Stiffness

Events

?dsolve,numeric,Events

Time events and state events

Event handling:

?MapleSimUserGuide,Chapter04:
section 4.1 How MapleSim Simulates a Model

Event iteration:

?MapleSimUserGuide,Chapter05:
section 5.5 Selecting the Code Generation Options

Iteration, hysteresis, Intermediate steps: ?tasks,generatingCode

Hysteresis:

Hysteresis in value or also in time?

Do variable solvers adapt the value of event hysteresis during runtime?

 

Baumgarte constraint stabilization, unconstrained dynamics, constrained dynamics

?MapleSim,Multibody,Dynamic_Exports
(in combination with ?MapleSim,Multibody,Kinematic_Exports)

?examples/numeric_DAE

?tasks,generatingCode

?MapleSimUserGuide,Chapter05:
section 5.5 Selecting the Code Generation Options

Error control

              ?dsolve,numeric,Error_Control

              Absolute error: ?dsolve,numeric,IVP

              Relative error: (relative to what?)

Index1 error control and Index1 Tollerance: see solvers

Scaling

scalemethod (this does not seem to exist in Maple)

 

Examples (Multibody)

Events

                            Catapult
                            (from MapleSim>Help>Examples>Physical Domains>Multibody)
                            contact events

                          Catapult_-_Events.msim

                            Throwing a ball
                            (from MapleSim>Help>Examples>Physical Domains>Multibody)

                            conditional events (with boolean logic)

                          Throwing_a_Ball_-_Events.msim

              Solvers

              Conservation of energy of a pendulum depends on solvers.
                           Euler increases energy, implict Euler dissipates energy.

             Pendulum_for_solver_comparision.msim

           

Constraint dirft/projection

              2-d rigid slider crank

               (from MapleSim>Help>Examples>Physical Domains>Multibody)

              projection off leads to assembly desintegration after 2000 s simulation

             2D_Rigid_Slider_Crank_-_constraint_projection.msim

                         A stiff solver improves constraint drift, but only delays desintegration

                         Baumgarte constraint stabilization prevents simulation error but shows dislocated rigid body frames

 

It can happen when an operation is interrupted by  that Maple does not return to  and still shows .

This can give the false impression that the Maple server in charge of the evaluation did not get the message to stop whatever it was doing.

By giving Maple an impossible task to solve analytically

f1 := x1 - x1*sin(x1 + 5*x2) - x2*cos(5*x1 - x2);
f2 := x2 - x2*sin(5*x1 - 3*x2) + x1*cos(3*x1 + 5*x2);
solve({f1, f2});

I have noticed in the Windows Task Manager that freeing allocated memory can take much longer than one might think.

In one case it took 30 minutes to free 24 Gb of total allocated memory (21 Gb of it in RAM/physical memory). In this case the interrupt button became active (turned from grey to red ) two times and memory continued piling up  again.

Lessons learned for me:

  • The task manager is not only a valuable indicator for task activity but also for the interruption/memory freeing process.
  • Before killing a whole Maple session and potentially losing the last state of a worksheet it can pay off to wait and repeatedly interrupt an operation.

 

Suggestion: When the maple server gets an interrupt request, it could report to the GUI that it is in an interruption state and is no longer evaluating input. For example changing the message in the status bar from Evaluating... to Interrupting...

1 2 3 4 5 6 Page 2 of 6