@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.

@sursumCorda 

Your solution is better than nothing. Thank you

@C_R 

With a stiffer contact without damping it is possible to let the pendulum swing without angular reflection (which I called angular lock) and some bouncing. The bouncing depends on mass distribution to the contact point. The last bounce below looks strong because the two masses are vertically alligned (i.e. the 1 kg mass hits the contact point head on).

The bouncing is also reflected in ramps of the angular orientation where we have lift-off. We see a slight dependence on the solver type. In the beginning the disk rocks smoothly. There is a high number of events indicating that the numerical integration with the variable step solvers needs reconfiguration. Fixed step solvers do not work.

Overall the model is too simplified to work well together with the sophisticated contact elements. The contact element cannot be parametrised in a way to be infinite stiff, sticky and without friction. What we see here is what can be expected as a consequence of the low fidely of the modeling. Its neither a bug nor an insufficient implementation.

@sursumCorda 

That works if I paste from your answer or from https://en.wikipedia.org/wiki/Greek_and_Coptic

Its a bit complicated. Do I get unicode within Maple?

@Rouben Rostamian  

I thought I had excluded this possibitly by adding a mass of 0.001 kg at the center of the spherical contact element that does the rolling.

What you assumed was no mass at the center:

Disk_pendulum-_strip_down.msim

Without friction it should behave now like a pendulum with a horizontal prismatic joint at the pivot point.

Kinematically it does: the mass is falling straigt down.

Energetically after the first swing, energy is lost. This should not be for a conservative system.

However, in the elastic contact I added a bit of damping.

One could argue that this system is unphysical because no lateral forces act.

Effectively we see only a mass bouncing vertically. The erratic swing of the massless ridig body frame to the center of the contact element is only the solver searching for a solution that satisfies a constraint condition. In a vertical postition there are two possibilites left and right to the vertical.

However, increasing to a mass at the center to 0.01 kg, i.e. 1%, is not sufficient. Only with 0.1 kg the effect vanishes. This is 10% of the excentric mass and unexpected high.

At the moment I am a little surprised that the problem is still illconditionned with a mass ratio of 1%.

Adding to @Rouben Rostamian suggestion: Once you have computed the normal force of the contact you could investigate for slippage. In this question about some numerical artefacts I have uploaded a MapleSim model that still shows slippage for mu=1.

To implement slippage, numerical integration has to switch between two configurations of odes: One for slippage and one for rolling without slippage (this one you have implemented already).

Maybe someone knows whether dsolves event control can be/has been used for this.

P.S.:

The red curve red below (with reduced slippage) shows a good agreement with your implementation 👍

@Gabriel Barcellos

Your interpretation is correct (based on one attempt using the procedure p_O2 in Médio_spin_7_2_-_Forum_optimize_03_b.mw) all results for varying d close to d=3 are the same.

Before zooming in I would now create a coarse d-T map. Finding solution far away from  d=3 seems to be difficult. So far I could not find anything.

Everything else next year.