Besslers prime mover and its enabler.

[Roxaway59]

Here it is Fletcher.
Graham

[Fletcher]

Here it is with a few mods - all I did was add some vectors ( acceleration and air force ) on the green top weight 23 gms - n.b. the red force vectors sometimes work and sometimes don't show on screen in my program .. have a play ..

Bottom line - metering the Acceleration and adding some other metrics it went from OU with air resistance ON to behaving how the physics says it should i.e. stops before going over tdc .. so looks like a bug which wakes up when you start some metrics .. cheers ..

...............

[Roxaway59]

Ok cheers Fletcher it just goes to show that simulators can be tricky.

Graham

[Roxaway59]

Fletcher one thing that struck me about this is if a simple non over unity design like this can become over unity then a more complex over unity design could become not over unity and I would be non the wiser.

Graham

[Fletcher]

Fletcher one thing that struck me about this is if a simple non over unity design like this can become over unity then a more complex over unity design could become not over unity and I would be non the wiser.

Maybe .. but .. as I've said all along you have to use your knowledge of classical physics and that is the benchmark or yardstick you use to see if your sim passes the 'reasonability' or plausibility test ..

Let's take your OU sim from your last posts here ..

It was a very simple device - just a pin jointed ( center pivot ) disk with 3 circular weights attached at the same radius - 1 topside weight of 230 gms and 2 side by side bottom weights of 20 gms and 3 gms iirc - the system COM was way above the axle and barely to the right of the y-axis vertical line - this should fall of its own accord because there is a CW torque allowing GPE to be converted to KE , IOW's it will turn IF the system can lose NET PE ( height ) .. you added a motor to the disk for a very short time to get it moving CW in addition to what gravity would have done on its own - because the motor has a set rpm value the disk and all components fixed to it ( the 3 masses ) will instantly have KE - then the conversion of PE to KE adds to the system KE after the motor turns off - there are no frictions but air friction is ON LOW .. it went over tdc appearing to predict OU ..

So an investigation was required - what I did was initially turn OFF air frictions and run the sim - it revolved almost back to the starting positions but stopped just short, as I would expect, unless the motor had to much rpm or ran for too long ..

Then I turned ON the air friction again - it went over tdc showing what appears to be an OU response to air friction turned ON - but the 3 weights are just very small diameter circles with no aero-dynamic lift ( from asymmetric shape ) but with air density on they do have some form drag which logically should have slowed the disk down - but it didn't and must have sped it up into OU territory ..

So my physics radar went off - this could to be a bug in the particular file ( coz I've never come across that before ), or the program .. so I possibly need to wake the program up and get it out of whatever loop it is in - so I added some other metrics like Acceleration so I could track and plot the objects acceleration to see when the wheel acceleration kicked in or whether it was gradual etc - and I changed the air friction k values to see if a trend developed - then I went back to air frictions off as the control experiment - it stopped before tdc sub OU - then I turned them onto low - AND - it stopped before tdc and more importantly before where it stopped with no air frictions ..

So given what I know about physics it was now not OU either with or without air frictions on - conclusion, it was probably stuck in some loop when you built the sim ( or your program ) and by trend testing it and adding more metrics it "woke" or "reset" the program to act correctly by making it cross-reference metrics etc ..

That is why I say if you get anything that looks like it is OU the next thing to do is 'stress test' the sim thru a range of values and metrics to see if the result/trends is consistent - if it is then its time to sit on the edge of your seat and rebuild it again from scratch or in a different program .. * caveat - I am not a coder or programmer and that is my laymans explanation *

** IMO this stress testing regime and double checking applies to the simplest sims that might show OU to anything more complex - but the sim "prediction" does not trump your own knowledge and instincts of classical physics, imo ..

ETA .. as for a bona-fide OU sim not showing OU and you not spotting it - same applies imo - " cause and effect " - what series of causations will or will not make it OU - if you know or suspect it should be OU then the sim should just be a cross check to your intuitions - unless its programing has a top down fail safe to keep everything aligned to COE in which case it might not even tho you have worked out all the daisy chain steps that should give OU ..

[daxwc]

Not sure why Algoodo would be doing it too.
Make a cheap real construction setup and find out Roxaway59.
It doesn’t make sense to me but I find the motion fascinating.

[johannesbender]

Fletcher one thing that struck me about this is if a simple non over unity design like this can become over unity then a more complex over unity design could become not over unity and I would be non the wiser.

Graham

I know you were addressing Fletcher , but might i just say , whether your sims shows ou or not , the real world still sits out your window so don't worry about being non the wiser because you could become more the wiser if need be Graham .

[Roxaway59]

Fletcher / Dax / JB, thanks for the input.

I do intend doing more things in the real world as I have been saying and for the time being I will try to use the simulators more carefully.

Why Algodoo behaves the way it does is a bit of a mystery because certain things it seems to do perfectly well. The real builds / experiments though always give the accurate answer and I just wish I could do those all the time.

I was working on a class D amplifier for a friend of mine today and that got me thinking about combined oscillations once again and Besslers wheel could have had a number of oscillations on it. When these oscillations combine maybe it could do something special to the wheel every half turn.

Graham

[SHADOW]

Bonjour Roxaway,
Peut être que les deux pendule entre en résonance et accumule l'impulsion nécessaire pour entretenir l'élan, comme pour l'expérience vibratoire du double diapason!


Hello Roxaway,
Perhaps the two pendulums resonate and accumulate the momentum needed to sustain the momentum, as in the double tuning fork vibrational experience!

[Georg Künstler]

by Roxaway59 » Mon Feb 10, 2025 10:26 pm

Fletcher / Dax / JB, thanks for the input.

I do intend doing more things in the real world as I have been saying and for the time being I will try to use the simulators more carefully.

Why Algodoo behaves the way it does is a bit of a mystery because certain things it seems to do perfectly well. The real builds / experiments though always give the accurate answer and I just wish I could do those all the time.

I was working on a class D amplifier for a friend of mine today and that got me thinking about combined oscillations once again and Besslers wheel could have had a number of oscillations on it. When these oscillations combine maybe it could do something special to the wheel every half turn.

Graham

Hi Graham,
I am here speaking for the one-directional wheel,
The wheel is working with a combined oscillation, that`s right.
And as you normally do an amplification, also in electronics, the phase is shifted by 180 degrees.
So your assumption that there is something special to the wheel after every half turn is correct.
A turning wheel is an oscillator, and on this oscillation you make the additional oscillation.
When the wave is at its maximum on the 3 o'clock position, it has also the maximum on the 9 o'clock position.
So 3 o'clock and 9 o'clock are synchronic, either to the left or to the right, but both at the same time.
This will result in net torque for the one-directional wheel.

You can compare it to a standing wave.

[Roxaway59]

Hi Shadow / Georg, sorry for the late reply I've been a bit busy with other things.

Yes its clear that besslers wheel had some kind of oscillation that wasn't straight forward.

So what we need to think about is oscillators that can act in odd ways that end up with more than one tuned oscillation on them.

As a simple demonstration in Algodoo look at the way this simple set up behaves.

This is what it does in my version of Algodoo.

Run the sim and then turn off the motor. You should see that its reluctant to pick up speed.

Reengage the motor and take it to 7 rpm then turn it off. Now you should see it pick up speed and you will see the framework rock as it resonates with the speed of the wheel. It then becomes unstable.

If you wish you can turn on air resistance and it will still do it but you will need to increase the speed to around 9 or 10 rpm.

Graham

[Roxaway59]

Basically this whole process is a slow process because we have so much experimenting that we can do.

The next step is to put it in WM2D and see how that behaves but at this stage I am more interested in the rocking motion at certain speeds than about WM2D going faster because I doubt that it will.

Graham

[Roxaway59]

This is an update on the last sim shown and just a thought that I want to convey that could be important.

As I looked at this sim with a view to replicating it in WM2D I noticed that the grid base was set to 4. I normally have it on 10 because then I can match it up with WM2D and know that what I build will be fairly accurate.

Because of this I built it using a grid base of 10 and tried to keep everything similar.

After doing it I tried the experiment again only to find that it behaved very differently even though weights and distances of things were similar. In fact I can only get it to pick up speed momentarily.

To me this means either one of two things.

Either Algodoo is just being Algodoo and everything its indicating is false or on the original build everything was just right and it behaved as it did because it is properly tuned.

If the second one turns out to be right then it could explain why it is that Besslers secret has remained undiscovered for so long.

This is not the first time I have thought of this because I have been making oscillators in Algodoo for years now and because Algodoo tends to act over unity you get to appreciate a potential oscillator in a way that WM2D doesn’t normally permit.

So let me put forward this hypothesis for Besslers two way wheels.

The wheel Bessler made was more like a huge tuning fork but with more than one frequency involved and it was mainly this oscillatory action that enabled the wheel to be out of balance.

In Besslers own words the answer was so simple and so hidden. So the opera singer only breaks the glass when the right frequency is sung. Until then nothing happens.

Maybe we shouldn’t have been concentrating mainly on mechanisms but more on frequency and tuning along with mechanisms that can blend in with oscillators.

I’m not suggesting that we haven’t done that to a certain degree, we have, but you only have to look at the amount of ideas that rely on a lot of brute force lifting to see that the focus is not on frequency and resonance in a lot of designs.

Graham

[Gregory]

Hi Graham,

I tested your sim file with the glitch, and I think I know what is happening...

Well, first thing to notice... The wheel in question is very small with a radius of 0.025 meters, aka 2.5 cm in radius. It's like the size of a bigger coin or cap. And we pin 0.001 meter, aka 1 millimetre radius weights to it. Like how many angels can dance on the head of a pin? :)

Also the wheel's mass is 0.04 kg, and if we calculate it's Moment of Inertia for example we got... 0.5 * 0.04 * 0.025 * 0.025 = 0.0000125 kg*m^2
Momentum and velocity growth will be based on this, and the calculations with this...

So, that's a kinda tiny number...
And the simulator is trying to work with these tiny numbers doing approximations for position, velocity, momentum growth/changes. When working with these small numbers the simulator will accumulate more and more error, because compared to these miniscule numbers, the size of the accumulated error (while being usually very small), in ratio will be bigger. I suspect that might be the problem here.

So, my advice is...
Use a larger metric and build bigger things with more mass, more realistic components, etc. Like a wheel should not be smaller than 0.2 m radius if possible. That way hopefully any calculation or rounding error will be tiny compared to the whole, and some might even randomly cancel out.

I attached a similar sim I recreated, but somewhat bigger. This one does not produce the effect, or at least unnoticeable.
I usually use a 0.7 m radius for testing wheels.

[Fletcher]

I think you nailed it Gregory - good job !