Sjack Abeling Gravity Wheel and the Worlds first Weight Power Plant

[mondrasek]

Omnibus

You play it with Flash Player (free player from Adobe.com)

ruggero  ;-)

Or drag and drop into any Internet Browser window.

[Omnibus]

@mondrasek,

If rigid joints are set to Optimized, Air Resistance is off, Animation Step is set to 0.050s and Integration Error set to 0.010m indeed represent ideal conditions as Hans considers them then perpetuum mobile under ideal conditions has been confirmed through sims. If that’s the case then it is very significant. Thus, it is very important to understand whether or not these conditions are indeed ideal conditions. Real world behavior is only a secondary consideration of purely engineering essence.

As for the slowness of the rendered slim, I’m not so sure how unimportant it is as to the physicality of the demonstration until I know what really is going on inside the program. Already rendered image should not depend on the speed with which the computer calculates (otherwise, say, videos will run at different speeds on different computers), only the calculation steps should. However, even if speed of the computer is important, you do not address the dropping out of constraints when decreasing the graininess of error limits. No matter what the accuracy, changing of constraints changes the model under simulation and the conclusions made, independent of how accurate the calculations, refer to a different model, not to the model under discussion.

[ruggero]

Or drag and drop into any Internet Browser window.

I don't know how you manage that....: When I drag'n'drop the .swf-file into Firefox (or if I try to open it from within Firefox "Open File"), it just ask me to download or make me choose an appropriate program to run the file.

Maybe it's in the preferences... but if you've installed the player it just works.

ruggero ;-)

[Omnibus]

@ruggero,

Yes, that drag and drop worked really well. That's exactly what we need to accomplish. Now I understand what the whole story is but we don't want to do it the way @Cherryman did it because it isn't symmetric and accurate enough. What is needed, but probably unachievable, is to have a one single rotor (not a rotor made up of several parts put together as @Cherryman usually does it) with eight smooth grooves. So far the grooves and tracks with complicated form were always drawn approximately, containing bumps and other imperfections which disturbs the analysis. The most we can do at this point, as far as I can see it, is draw one closed curve of a proper form and then mirror it eight times, put all these eight parts together, import them in wm2d and then fasten them onto a background disc just as @Cherryman does. Not only this is a hell of a job, as I mentioned previously, but it isn't the accurate model we're aiming at.

[mondrasek]

If rigid joints are set to Optimized, Air Resistance is off, Animation Step is set to 0.050s and Integration Error set to 0.010m indeed represent ideal conditions as Hans considers them then perpetuum mobile under ideal conditions has been confirmed through sims. If that’s the case then it is very significant. Thus, it is very important to understand whether or not these conditions are indeed ideal conditions. Real world behavior is only a secondary consideration of purely engineering essence.

Ridged joint (vs others, Optimized or not), Animation Step, and Integration Error are not values that have an ideal condition.  Using a method for modeling items that minimizes calculation errors is something that may differ based on the system you are modeling.  So trying alternates is always a good test procedure.  You should not expect to learn one way that works best for all cases.

And since as the Animation Step and Integration Error become ever smaller the sim becomes ever more precise (yet more computer hardware intensive) these cannot ever be ideal (set to zero).

The proper methodology is to make a simple model with the best known techniques and run at a reasonable time step.  Then if you witness strange behavior or need more precise measurements, try alternative modeling techniques (if they exist) and decrease the time step.  So far this method has worked to show exactly zero perpetual motion devices.  Only tricks to fool the sim have.

Running without friction, elasticity of 0 or 1, and without air resistance, are the examples of ideal conditions that can be used when first analysing a sim.

As for the slowness of the rendered slim, I’m not so sure how unimportant it is as to the physicality of the demonstration until I know what really is going on inside the program. Already rendered image should not depend on the speed with which the computer calculates (otherwise, say, videos will run at different speeds on different computers), only the calculation steps should.

The program is obviously not just rendering frames of a movie.  If it were, like you say, then it should be able to run near real time (at reasonable Animation Step setting) once it playing back already rendered frames.  But this is not the case.  In fact, the program taxes my CPU the same whether playing quickly through a previously calculated sequence, or chugging slowly through it the first time.  My guess here is that only portions of pre-calculated frames are saved, like a pre-pocessing step.  The results must still be finalized by the engine and rendered.

However, even if speed of the computer is important, you do not address the dropping out of constraints when decreasing the graininess of error limits.

I have not address this because I agree it is an issue.  But not a show stopper.  I believe this error might also not mean that a constraint is being dropped indefinitely, but only that one of two or more conflicting constraints must be ignored in any one iteration.  Allowing the sim to continue gives one of two outcomes:  Either it blows up noticeably, or continues on without any apparent ill effect.  So it handles the error just like it is doing with every calculation error it makes due to it's iterative structure.  And still, the program returns lifelike results.  If it showed something unexpected, it would be cause for further investigation, in the sim, and possibly in real life.

No matter what the accuracy, changing of constraints changes the model under simulation and the conclusions made, independent of how accurate the calculations, refer to a different model, not to the model under discussion.

No.  It changes the parameters under which you are testing the model.  The same way I can test a car in the heat of a desert or the Arctic cold and still be testing the same car.  I could even take the car to the moon and test it under lower gravity in theory.  The sim allows the same type of testing.  You just have a lot of control for parameters you may take for granted in real life testing, and that can be useful or harmful to your efforts based on your own testing methodology.

WM2D is a tool.  With proper methodology, it can be very useful for testing our wheel ideas.  The proper methodology will likely change depending on which design and characteristics are being analyzed.