Question to those who use simulation programs.

[johannesbender]

im a simple guy , not very advanced as the rest with sims , the tools i use are more a visual learning and design tool for me at this point.

although i am a fully self taught , tool/game software coder/scripter , i never went deep enough in to physics coding to care about laws and violations.

i did find a pdf of wm2d with this , dont know much more in depth information of what is beneath the bonnet ,except that it seems they assume system gain may happen due to accuracy .

there is also a few listings of the formulas used in the sim.

[Fletcher]

Yeah .. it's what is being discussed on Mr V's thread in part. He's trying to discount this in his rigs.

We've seen countless examples of people appear here saying "take a look at this anomalous result. The sim is gaining energy (either KE of GPE) from this simple action."

Usually it is a matter of accuracy control, and sometimes using variable iterations steps rather than fixed. That's because the sim goes forward in time step (calculate positions, forces, and velocities etc) by step. From that a kinematic picture film develops (frame by frame) which you see as the sim running but do not discern any frames, unless the accuracy is set deliberately very low.

The problem is that the program is designed to pick up contacts between objects. And even tho they have elasticity factors (just like real world) two objects might be just apart in one frame, but overlapped in the next (depends on velocities as well). Beyond elasticity and accuracy tolerances. So the program "spits out" the overlapping objects (a protocol violation) and the anomalous energy gain occurs.

So one of the first things you do is set accuracy to a higher value, but its a compromise. Not too many steps to take hours to run the sim. Not too little so that overlap errors and anomalous energy gains occur. Tho they're not anomalous coz you know what's causing them.

If the sim looks promising then you up the accuracy level, or if parts have high velocities, then you have to manage the situation by increasing accuracy or changing to variable integration steps.

So it's just a program knowledge and management of program limitations situation. Real world doesn't have to think about or manage those things.

[eccentrically1]

In my opinion, if Bessler's wheel proves the fundamental laws to be incorrect (which i don't think is the case) the sims will not be able to do it and if bessler's wheel proves that we have been incorrectly applying the laws then the sims will work.
Just my two bob worth.

Yes, thanks RH. That's along the same lines of what I was saying.
But, I'm not sure wm2d could sim his long duration wheels even if we knew how they worked beforehand.

So the question for wm2d is can it simulate PM while not violating those fundamental laws? It's a catch 22.
If it can, the laws are correct (no violation).
If it can't, the laws are correct.
If it's a program error or limitation or accuracy or protocol, the laws are correct.
If it violates the laws and no errors were made or protocol broken, then after building it, it should work in the real world and the laws would change.

[johannesbender]

Yeah .. it's what is being discussed on Mr V's thread in part. He's trying to discount this in his rigs.

We've seen countless examples of people appear here saying "take a look at this anomalous result. The sim is gaining energy (either KE of GPE) from this simple action."

Usually it is a matter of accuracy control, and sometimes using variable iterations steps rather than fixed. That's because the sim goes forward in time step (calculate positions, forces, and velocities etc) by step. From that a kinematic picture film develops (frame by frame) which you see as the sim running but do not discern any frames, unless the accuracy is set deliberately very low.

The problem is that the program is designed to pick up contacts between objects. And even tho they have elasticity factors (just like real world) two objects might be just apart in one frame, but overlapped in the next (depends on velocities as well). Beyond elasticity and accuracy tolerances. So the program "spits out" the overlapping objects (a protocol violation) and the anomalous energy gain occurs.

So one of the first things you do is set accuracy to a higher value, but its a compromise. Not too many steps to take hours to run the sim. Not too little so that overlap errors and anomalous energy gains occur. Tho they're not anomalous coz you know what's causing them.

If the sim looks promising then you up the accuracy level, or if parts have high velocities, then you have to manage the situation by increasing accuracy or changing to variable integration steps.

So it's just a program knowledge and management of program limitations situation. Real world doesn't have to think about or manage those things.

Physical simulators differ in the way they react on a collision. Some use the softness of the material to calculate a force, which will resolve the collision in the following time steps like it is in reality. Due to the low softness of some materials this is very CPU intensive. Some simulators estimate the time of collision by linear interpolation, roll back the simulation, and calculate the collision by the more abstract methods of
conservation laws .
Some iterate the linear interpolation ( Newton's method) to calculate the time of collision with a much higher precision than the rest of the simulation. Collision detection utilizes time coherence to allow even finer time steps without much increasing CPU demand, such as in air traffic control.
After an inelastic collision, special states of sliding and resting can occur and, for example, the Open Dynamics Engine uses constraints to simulate them. Constraints avoid inertia and thus instability. Implementation of rest by means of a scene graph avoids drift.
In other words, physical simulators usually function one of two ways, where the collision is detected a posteriori (after the collision occurs) or a priori (before the collision occurs). In addition to the a posteriori and a priori distinction, almost all modern collision detection algorithms are broken into a hierarchy of algorithms. Often the terms "discrete" and "continuous" are used rather than a posteriori and a priori .

yeah short of owning a supercomputer you cant do much about it.

[Georg Künstler]

Robinhood46 wrote:

Quote:
Therefore we have to preload the Besslerwheel with Gravity energy.

Do you mean; put a weight in it somewhere that isn't at the bottom or does it mean something else?

A preloaded system with gravity is a system which has already Gravity energy in itself.

A normal weight has the energy E = m*g*h.
What I do is, to load the spring, compress the spring with the weight. And in addition I have the potential energy. So I have 2 times energy.


I had given you an example with 8 weights, which always will compress 2 springs at the bottom. if you lock the spring at 6 o'clock, in the compressed mode, the weight can travel on a short lever arm up to the position to 12 o'clock. You release the locked spring and create the long lever arm.

[Daniel.R]

I, for one, think your reasoning is very sound, Ovaron. I have been working with both WM and Algodoo for a long time, and over the past few weeks, I have begun to understand where you are coming from, Ovaron. My conviction grew stronger when I realized that neither Algodoo nor WM can simulate a Newton's cradle correctly. The inner workings of energy exchange are too complex and of too fine a resolution for computers to handle accurately.

For example, it is easy in Algodoo to create an arrangement of springs and weights that will perpetuate motion due to how Algodoo calculates hinges. The hinges in Algodoo stretch in a manner that creates energy out of nothing. This alone makes searching for a working mechanism in Algodoo, and possibly WM, a huge waste of time, in my opinion.

My reasoning is therefore similar to yours, Ovaron, and I believe that the effect or energy exchange that Bessler found cannot be discovered or simulated with a computer program.

Bessler searched for years and possibly built many hundreds of contraptions to finally find the solution.

My idea now is to create some sort of perpetual motion science kit in the likeness of a children's science experiment toy box, including levers, pulleys, weights, strings, and so on, to experiment and play with. Sure, it will take more time and cost me some money, but the results I see will be completely grounded in reality and real-world physics. The thought alone actually feels like a relief and a step in the right direction.

[Tarsier79]

My conviction grew stronger when I realized that neither Algodoo nor WM can simulate a Newton's cradle correctly.

WM can simulate a Newtons cradle perfectly, or with any given frictions or elasticity.

[Daniel.R]

That's strange. Yesterday, a Newton's cradle wouldn't work in either WM or Algodoo. But today, after playing around a little more, I got it working in both sims. Oh well, my thoughts on the matter still stand.

[Sam Peppiatt]

ovaron,
Best I can tell, simulations are of little or no value for inventing a gravity wheel. However, they would be invaluable for demonstrating one, after you find out how to do it--------------------Sam

ETA Seams to me like no one has learned any thing, from simulations, FWEIW