@Rouben Rostamian  

Beautiful. It's kind of a double pendulum that is not chaotic. I have to think about it (and how to make it chaotic)

@mmcdara 

Thank you too. MapleSim is a good explorative tool but also kind of a grey box. The governing equations of motion are not intended to be easily understandable. MapleSim assembles them for efficient computation.
For example, I have not found a good explanation why the vector of agular acceleration (orange) is perpendicular to the initial axis of rotation. Note also the flip the red and green forces.

For a further analysis, I think, Maple has to be involved.

@Mariusz Iwaniuk 
What about solutions exploiting symmetry?

int(cos(cos(x)),x=0..1/2*Pi)
                       1                 
                       - Pi BesselJ(0, 1)
                       2                 

and 3/2 Pi, ...

Here again Maple does not take periodicy into account.

Or:

int(sin(sin(x)),x=0..3/2*Pi)

I am wondering whether Mma hard codes such results or uses an algorithm that identifies periodicy.

By the way: AI does not know the answer to any of those integrals (yet).

@Christopher2222 

The fix: Deleting all demultiplexers and inserting new ones from the library.

@Christopher2222 

Thank you. In this case MapleSim was particulary good to quickly explore things and to get numerical results.

@Christopher2222 

The post is worth emphasizing. It provides clean and documented Maple code for the equations of motion by Rouben Rostamian using quaternions. 

@Carl Love

Since I had to leave mechanics a long time ago, I would need feedback and advice on what is worth publishing and where. I have no idea which part could offer added value in which (scientific) domain.

A journal like Maple Transaction would be suitable but such a thing does not seem to exist for work mostly done with MapleSim. Perhaps @rcorless can tell how much explicit Maple must be inside a Maple Transaction publication.

I am pleased that the post could provide more than only details on MapleSoft tools.

@nm 

I can confirm the errors and that it is not fully reproducible (no clear pattern) as one would expect.

I can also confrim that with Maple 2022 I do not see the error messages at all.

This is a nasty bug.

If I had time I would now compare Maple 2022 and 2024 side by side or I would look for a case that is 100% reproducible.

The explanations for the partial cylinder geometry in

?componentLibrary,multibody,visualization,CylindricalGeometry

helped to understand what to do.

(Its the first time I use this component. Beginner error: Wrong intuition and wrong interpretation of the orientation of the base frame in the help page.)

@mayzal 

I cannot find that you set boundary conditions for velocity_dimensionless when I enter.

indets({BCS})

Please check

I have no experience with pdsolve but the error message indicates the that the problem is related to the definition of the BCs.

It could either be that there is a pde too much for one of the depended variables or that one depended variable does not depend on time.

You have in total 7 dependend variables 

P_dimensionless(z, t), T_dimensionless(z, t), Tw_dimensionless(z, t), velocity_dimensionless(z, t), X_dimensionless[1](z, t), X_dimensionless[2](z, t), Y_dimensionless[1](z, t)

8 boundary conditions and 6 initial conditions. Is that correct and what you want to do? Is it further correct that two of the boundary conditions depend on other boundaray conditions? Maybe Maple cannot deal with such combined BCS.

I am affraid that I cannot help further but perhaps this clarification can kick-off answers.

@Samir Khan 

Why not installing the previous version until a fix is available?

Since Maple Flow is built on Maple I expect the same interrupt behaviour. Sometimes it can pay of to wait. See here.

Alternatively, you could try to kill the mserver.exe process and reload the document. Optionally saving your work before reloading.

@Rouben Rostamian @Christopher2222

Also fixed step solvers reproduce two physical effects when the step size is reduced:

• reflection
• double rebounce

Reflection:

When the contact force is maximal (A), the velocity of the center of the disk is zero (B and C) and the penetration into the contact is max (F).

Since the contact force does not point to the center of mass of the disk (D), a torque is generated that lets the disk roll back. The torque is alo responsible for the deceleration of the horizontal velocity of the tiny mass.

Double rebounce:

After lift-off we see a second contact (E). This is caused by the backward rotation generated by the torque. The disk rotates fast ennough about the center of mass of the disk that the outer contour of the disk hits the flat surface a second time.

Does this make sense? (An extended explanation will take more work and is maybe worth a post visualising the contact force and the contact location. Both are not provided by MapleSim).

simplified_disk_pendulum.msim

Concerning the dislocated mass: This did not manifest with the above model and still might be related to solvers. (edit:) because the integration time ways shorter and more plot events where generated. -> It's a plot artefact.

Exporting the DAEs to Maple looks like this (just to give you an idea)

simplified_disk_pendulum_Equation_extraction.mw

@Christopher2222

I use MapleSim 2024.

I could not fix warnings and the initialization problem but I know where they are comming from. It is a connection between two scalar ports which is interpreted as an array to scalar connection. I can work around that but the effect at 12.5 s is still there.

I had a closer look at a "reflected" bounce (0.01 kg, d=0 (no damping), c=100000 N/m stiffness) similar to the bounce at 12.5 s. It's also not physical what we see there. The horizontal speed of the tiny mass changes (green) abruptly when the fat mass bounces.

Also the fat mass dislocates during the bounce while for m=0.1 kg (to the left) it stays in place.

This looks like a solver finding other solutions than the correct one.

I "bounce" back to my orginal surprise that I did not expect this for a mass ratio of moderate 1:100.

The solvers somehow have difficulties in keeping the horizontal speed contineous when the tiny mass crosses over the fat mass. I will see whether I can find setting that work better. If not I will try to export the DAE system for analysis in Maple.