Product Suggestions

Post your suggestions on new features and products.

First impressions, I have mixed feelings - one being it's cool and new, the other feeling that it's a bit clunky.

In my opinion Maple is starting to look like the interface is being modelled after Microsoft Office, or like the ribbon toolbars of AutoCad or Inventor.  Maple's "uniqueness" is disappearing.  I rather liked the old interface. 

The toolbar icons are larger, taking up more space.

The toolbar layout is indeed simpler, but also less efficient maybe.  I mean there were more useful available icons at once before, more functional is the word I guess.  Now it might be a couple of clicks away to pull up your favorite icon(s).  The icons all look very nice, that's a plus but they could be smaller.  

Perhaps we could make a customized menu toolbar?  That is, allow users to put all the most useful icons we use or would like the most to be displayed?  This would help some of the strange organization of some of the icons and allow us to make our maple "sandbox" feel more at home. 

(1) The gray line above the working area is redundant.

(2) Line Style, Color, and the "Delete" key function to delete object are not working properly.

(3) IdentifySequence([1,3,5,7,9]) without the second argument does not work.

(4) IdentifySequence should first identify simple patterns (Arithmetic Progression, Geometric Progression, Arithmetic-Geometric Progression, Harmonic Progression) before attempting to find a more complex formula for the nth term of the sequence.

(5) It would be beneficial if IdentifySequence recognized sequences involving rational, irrational and symbolic numbers.

I teach math at the high school level.

I am worried that Maple 2025 appears to be slower than Maple 2024 - in particular for students with older, less strong laptops.

Maple 2025 takes 50% longer to start than Maple 2024 (or Maple 2025 Screen Reader which I expect to be using).

So, on more sluggist student laptops I fear the slowness overall will be an issue - in particular as Maple regularly has to be shutdown and restarted for some of those students.

Further, I really miss the "recompute section !" and the "magniffy" icons on the quest access bar. Having "recompute entire worksheet !!!" seems unwise though. I wish you could costumize the quest access bar.

Overall, from a teaching point of view, I am not at all impressed, sadly.

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.

Deflection of a circular cantilever

(a first attemp with the AI formula assistant)

_local(I)

I

(1)

AI prompt: Deflection of a circular cantilever with a  force applied at the end

Correct formular inserted ->
delta = F*L^3/(3*E*I)

delta = (1/3)*F*L^3/(E*I)

(2)

AI prompt:  Moment of inertia of a circular cross-section

Correct formular inserted ->

I = (1/4)*Pi*R^4

I = (1/4)*Pi*R^4

(3)

subs(I = (1/4)*Pi*R^4, delta = (1/3)*F*L^3/(E*I))

delta = (4/3)*F*L^3/(E*Pi*R^4)

(4)

params := R = 25*Unit('mm'), F = 200*Unit('N'), L = 1.*Unit('m'), E = 210000*Unit('N'/'mm'^2)

R = 25*Units:-Unit(mm), F = 200*Units:-Unit(N), L = 1.*Units:-Unit(m), E = 210000*Units:-Unit(N/mm^2)

(5)

subs(R = 25*Units:-Unit(mm), F = 200*Units:-Unit(N), L = 1.*Units:-Unit(m), E = 210000*Units:-Unit(N/mm^2), delta = (4/3)*F*L^3/(E*Pi*R^4))

delta = 0.1034759757e-8*Units:-Unit(N)*Units:-Unit(m)^3/(Units:-Unit(N/mm^2)*Units:-Unit(mm)^4)

(6)

simplify(%)

delta = 0.1034759757e-2*Units:-Unit(m)

(7)

NULL

The dimension of m^9 for a deflection clearly indicates an error.

A better prompt to avoid this error (caused by automatic simplification) could not be found

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.

I don't have the latest Maple, and I'm sure this isn't in the latest version. 

One thing that has been an annoyance for all time, and it gets me time and time again, is not having a global degrees or radians setting. 

Of course it needs to be a setting option, otherwise it would break many older worksheets. 

fyi, there is new video showing Maple's 2025 new interface

It seems oriented to document mode which I do not use. May be they also improved worksheet mode.

I am still getting my Maple desktop getting shuffled few times each day where I have to close Maple and reopen it to clear it. I hope they fixed this in the new interface.,

To Maplesoft,

Please consider changing the name from Maple to something else.

It is almost impossible to search for anything related to maple, since google keeps giving results about trees called Maple in Canada and about some maple syrup products which I have no interest in at all.

One has to go through pages and pages of links looking for a real Maple software hit.

I know the name Maple has been around for long time, but a new unique name will make searching easier and people will get used to the new name very quickly (may be in 1-2 years).

Some examples:

 

I know when Maple was created almost 40 years ago, the inernet itself was not even here (I forgot when VP. Gore created the internet but I think that was in early 90's), and search was not thought about then.

But these days, the ability to search for something and to easily find it is very important for companies and having a unique name for Maple will make it also much more popular and easier to find things about it instead of finding  information about Maple syrup and Maple trees all the time.

This is posted  under product suggestions.

Greetings, dear Maple developers!

I, Yegor Volovodenko, together with my supervisor, Igor Zinoviev, Associate Professor, Head of the Department of General Mathematics at ZNU, am conducting research on ‘Solving equations and inequalities of elementary mathematics by means of computer mathematics: opportunities, problems and ways to solve them’. I express my sincere gratitude for your work on the development and popularisation of mathematics, for the constant improvement and enhancement of CAS in particular.

Unfortunately, during the study, we found some, in our opinion, shortcomings in the work of Maxima algorithms for solving elementary equations and inequalities

  1. Solving equations with parameters;



    In these two cases, the solution obtained is formal, without analysing the cases when the coefficient of a variable is zero. Thus, not all solutions of equations with a parameter are obtained. I believe that if the user is not familiar with the methodology for solving equations with parameters, he or she may lose some solutions that may be important for further work. So the solution can be considered incomplete.

 

  1. Solving equations with two variables.
     

In the equation with two variables, the answer was given in complex numbers, which is incomprehensible to a person who is not familiar with complex numbers. There are also comments on the course of the solution, in this equation it was necessary to select the square of the difference, and then solve the equation x^2+(y-2)^2=0, getting x=0, y=2.

I hope that the results I have obtained (the identified shortcomings) will help to correct the work of the algorithms and improve the work of the Maple system.

Sincerely, Yegor Volovodenko, Igor Zinoviev.

Try it yourself, you will understand what I mean. (MF2024.2.1)

 

Referring to the screenshots, "J" can be converted to "N m" in MF2024.1, but not in M2024.2.
Is this some sort of bug in M2024.2?

 

 

With the new release of Maple Flow 2024.2 the units "Area" and "Speed" don't work.

I run a MaxBook Pro with macOS Sequoia 15.2 and uninstalled MF2024.2.

 

I am a new user of Maple Flow 2024.2.

Since I installed this version I got trouble with the following commands:

solve(x^3-2x^2+3x-2)=1.00.  Just 1 root is returned

fsolve((x-2)(x+3)(x-1))=-3.  Just 1 root is returned

ifactors(3024)=.   Maple Flow latch in and crashes without errot massage

seq(i^2,i=1..5)=. Sequence not executed

subs(...)= Substitute not executed

Optimization:-Minimize(...)=.  Latch in, error


With the help of the Maplesoft-Team I uninstalled and installed several times MF on a MacBook Pro Sequoia 15.2 and on a MacBook Pro Ventura 13.7.2 with and without Firewall and McAfee. 
No success, the problems still remain.

I'll no longer use Maple Flow in this version.
I expect a new update asap!

I think a new integer subtype is needed: integer greater than one, gtoint.

isgto := proc(x::anything)
  local X;
  X:=x;
  return type(X,integer) and (X>1);
end:

AddType(gtoint,z->not isgto(z));

Major deficiency in Physics[Vectors]; Distinct sets of basis vectors are not recognized!

You can't define vectors in alternative bases like: {\hat{i}',\hat{j}',\hat{k}'} or {\hat{i}_{1},\hat{j}_{2},\hat{k}_{3}}.

This deficiency has been around for a while. I have found other posts regarding this problem.

The deficiency greatly reduces the allowable calculations with Physics[Vector].

Are there any plans to fix this?

Here is my example which shows this deficiency in more detail.

physics_vectors_and_multiple_unit_vectors.mw
 

restart

NULL

NULL

with(Physics[Vectors])

[`&x`, `+`, `.`, Assume, ChangeBasis, ChangeCoordinates, CompactDisplay, Component, Curl, DirectionalDiff, Divergence, Gradient, Identify, Laplacian, Nabla, Norm, ParametrizeCurve, ParametrizeSurface, ParametrizeVolume, Setup, Simplify, `^`, diff, int]

(1)

NULL

Crucial Deficiency in Physics[Vectors]

 

NULL

I can only guess the purpose of the Physics[Vectors] package from reviewing it's corresponding help documentation. My interpretation of the documentation leads me to believe that the package is best used for generating vector equation formulas in different coordinate bases of a SINGLE coordinate system.

 

This means one can easily generate position vector expressions such as:

 

r_ = _i*x+_j*y+_k*z

r_ = _i*x+_j*y+_k*z

(1.1)

Cylindrical Position Vector

 

The position vector in a cylindrical basis is given by:

 

r_ = ChangeBasis(rhs(r_ = _i*x+_j*y+_k*z), 2)

r_ = (x*cos(phi)+y*sin(phi))*_rho+(cos(phi)*y-sin(phi)*x)*_phi+z*_k

(1.1.1)

r_ = ChangeBasis(rhs(r_ = _i*x+_j*y+_k*z), 2, alsocomponents)

r_ = _k*z+_rho*rho

(1.1.2)

NULL

NULLNULLNULL

Spherical Position Vector

 

NULL

r_ = ChangeBasis(rhs(r_ = _i*x+_j*y+_k*z), 3)

r_ = (y*sin(phi)*sin(theta)+x*sin(theta)*cos(phi)+z*cos(theta))*_r+(y*sin(phi)*cos(theta)+x*cos(phi)*cos(theta)-z*sin(theta))*_theta+(cos(phi)*y-sin(phi)*x)*_phi

(1.2.1)

r_ = ChangeBasis(rhs(r_ = _i*x+_j*y+_k*z), 3, alsocomponents)

r_ = r*_r

(1.2.2)

NULL

NULL

As is known from the vector analysis of curvilinear coordinate systems the basis vectors can depend on the coordinates in question.

 

In cylindrical, the basis vectors are

 

_rho = ChangeBasis(_rho, 1)

_rho = _i*cos(phi)+sin(phi)*_j

(1.2)

_phi = ChangeBasis(_phi, 1)

_phi = -sin(phi)*_i+cos(phi)*_j

(1.3)

and in spherical, the basis vectors are

 

_r = ChangeBasis(_r, 1)

_r = sin(theta)*cos(phi)*_i+sin(theta)*sin(phi)*_j+cos(theta)*_k

(1.4)

_theta = ChangeBasis(_theta, 1)

_theta = cos(theta)*cos(phi)*_i+cos(theta)*sin(phi)*_j-sin(theta)*_k

(1.5)

_phi = ChangeBasis(_phi, 1)

_phi = -sin(phi)*_i+cos(phi)*_j

(1.6)

NULL

NULL

NULL

Example of this Deficiency using Biot-Savart Law

 

NULL

Biot-Savart law can be used to calculate a magnetic field due to a current carrying wire. The deficiency in question can be observed by explicity constructing the integrand in the Biot-Savart integral defined below.

NULL

NULL

NULL

In electrodynamics, quantum mechanics and applied mathematics, it is common practice to define a position of observation by a vector `#mover(mi("r"),mo("→"))` and a position of the source responsible for generating the field by a vector diff(`#mover(mi("r"),mo("→"))`(x), x).

 

It is just as common to define the difference in these vectors as

 

l_ = r_-(diff(r(x), x))*_

l_ = r_-`r'_`

(1.3.1)

and thus

 

dl_ = dr_-(diff(dr(x), x))*_

dl_ = dr_-`dr'_`

(1.3.2)

as found in the integrand of the Biot-Savart integral.

NULL

It suffices to consider `#mover(mi("l"),mo("→"))` = `#mover(mi("r"),mo("→"))`-`#mover(mi("r'"),mo("→"))` in a cylindrical basis for this argument.

 

The observation position is:

 

`#mover(mi("r"),mo("→"))` = rho*`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`+z*`#mover(mi("k"),mo("∧"))`

NULL

The source position is:

 

diff(`#mover(mi("r"),mo("→"))`(x), x) = (diff(z(x), x))*(diff(`#mover(mi("k"),mo("∧"))`(x), x))+(diff(rho(x), x))*(diff(`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`(x), x))

NULL

`#mover(mi("l"),mo("→"))` = `#mover(mi("r"),mo("→"))`-(diff(`#mover(mi("r"),mo("→"))`(x), x)) and `#mover(mi("r"),mo("→"))`-(diff(`#mover(mi("r"),mo("→"))`(x), x)) = z(x)*`#mover(mi("k"),mo("∧"))`-(diff(z(x), x))*(diff(`#mover(mi("k"),mo("∧"))`(x), x))+rho*`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`-(diff(rho(x), x))*(diff(`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`(x), x))

NULL

The deficiency in question arises because MAPLE cannot define multiple unit vectors in distinct bases such as {`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`, diff(`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`(x), x)} or {`#mscripts(mi("ρ",fontstyle = "normal"),mn("1"),none(),none(),mo("∧"),none(),none())`, `#mscripts(mi("ρ",fontstyle = "normal"),mn("2"),none(),none(),mo("∧"),none(),none())`}.  These pairs of unit vectors arise naturally, as shown above in Biot-Savart law.

NULL

If we look at `#mover(mi("ρ",fontstyle = "normal"),mo("ˆ"))` and  diff(`#mover(mi("ρ",fontstyle = "normal"),mo("ˆ"))`(x), x) generally, they look like:

NULL

`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))` = `#mover(mi("i"),mo("∧"))`*cos(phi)+sin(phi)*`#mover(mi("j"),mo("∧"))`

NULL

diff(`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`(x), x) = (diff(`#mover(mi("i"),mo("∧"))`(x), x))*cos(diff(phi(x), x))+sin(diff(phi(x), x))*(diff(`#mover(mi("j"),mo("∧"))`(x), x))

NULL

If the bases vectors {`#mover(mi("i"),mo("∧"))`, `#mover(mi("j"),mo("∧"))`, `#mover(mi("k"),mo("∧"))`} and {diff(`#mover(mi("i"),mo("∧"))`(x), x), diff(`#mover(mi("j"),mo("∧"))`(x), x), diff(`#mover(mi("k"),mo("∧"))`(x), x)} are Cartesian and are not related related through rotations so that

NULL

"(i)*i' =(|i|)*|i'|*cos(0)=1"``NULL

NULL

"(j)*(j)' =(|j|)*|(j)'|*cos(0)=1"NULL

NULL

"(k)*(k)' =(|k|)*|(k)'|*cos(0)=1 "

NULL

and so,NULL

 

`#mover(mi("i"),mo("ˆ"))` = diff(`#mover(mi("i"),mo("ˆ"))`(x), x)

NULL

`#mover(mi("j"),mo("ˆ"))` = diff(`#mover(mi("j"),mo("ˆ"))`(x), x)

NULL

`#mover(mi("k"),mo("ˆ"))` = diff(`#mover(mi("k"),mo("ˆ"))`(x), x)

NULL

the radial unit vectors in cylindrical are then,

 

`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))` = `#mover(mi("i"),mo("∧"))`*cos(phi)+sin(phi)*`#mover(mi("j"),mo("∧"))`

NULL

diff(`#mover(mi("ρ",fontstyle = "normal"),mo("∧"))`(x), x) = `#mover(mi("i"),mo("∧"))`*cos(diff(phi(x), x))+sin(diff(phi(x), x))*`#mover(mi("j"),mo("∧"))`

NULL

In typical problems, the anglular location of the observation point, φ, is distinct from the angular location of the source, diff(phi(x), x) and so under this condition, `#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))` <> diff(`#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))`(x), x).

 

Consider the classic problem of the magnetic field due to a circular current carrying wire. Surely, the angular coordinate of one location of the current carrying wire  is different from the angular coordinate  of an observation point hovering above and off-axis on the other side of the current carrying wire. See figure below.

NULL

NULL

NULL

NULL

Therefore,

 

`#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))` <> diff(`#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))`(x), x)

NULL

NULL

What happens in MAPLE when you try to define a second distinct unit vector diff(`#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))`(x), x)?

NULL

One can easily find `#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))`.

NULL

_rho

_rho

(1.3.3)

NULL

NULLIf you try to define diff(`#mover(mi("&rho;",fontstyle = "normal"),mo("&and;"))`(x), x) ...

 

 

diff(_rho(x), x)

`_rho'`

(1.3.4)

So using a prime doesn't work.

NULL

You could try a numbered subscript...

`_&rho;__2`

_rho__2

(1.3.5)

but that doesn't work.

 

You could try an indexed unit vector...

NULL

_rho[2]

_rho[2]

(1.3.6)

which can be define but is not recognized by Physics[Vectors] since...

 

NULL

ChangeBasis(_rho[2], 1)

Error, (in Physics:-Vectors:-Identify) incorrect indexed use of a unit vector: _rho[2]

 

NULL

And so it's just not possible with the current implementation.

``

``

NULL

NULL


 

Download physics_vectors_and_multiple_unit_vectors.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?
  • ...
     
1 2 3 4 5 6 7 Last Page 1 of 24