Forces from a Weight & 2 Strings

[Bill_Mothershead]

I wrote a program to simulate the interaction of a weight pulling down
on two strings...one string attached to the surface of a rotating wheel.
(Explained on website)

Fixed up the program to generate some LARGE animated .GIFs
which would probably be inappropriate to try to upload here.

Looks promising...but concept needs some review/comments.

Would welcome suggestions for refinements or new projects.

http://www.inficad.com/~moth/Bessler9.html

[sleepy]

Howdy,
Nice job on the GIFs.I have tried literally hundreds of scenarios involving this idea and it always resulted in zero net torque.Watch the animation carefully and you'll see that the weight is acting on the wheel negatively for far longer than it provides torque.You must also take into consideration that the force of the weight will not act equally on the wheel at One O'clock versus Nine O'clock.Also,it seems that your string lengths are not changing quite as they would in the real world.Thanks for sharing though.

[Bill_Mothershead]

Thank you for your posts.

Your goal when you "tried...hundreds of scenarios" was probably
to hunt for a scenario to keep the wheel rotating.

Noble goal...very ambitious.

Ultimately that is the right goal but that is like step 5, and the
stuff here is just step 1.

The goal here is mathematical validation.
Remember all those calculus classes and finding the area under the curve?
That is all that is going on here.

Trying to get a single equation that describes the rotation of a wheel
with the strings and the weight, etc. is beyond me, so using formal
calculus to integrate is a lost cause.

Fortunately, it is common practice in situations like this to get a useful
approximation by using a computer to simulate many small steps,
compute the torque at each step, and then sum up all the steps.

Crudely put, this is somewhat like counting colored pixels.
In the animated GIFs, for the graph on the right, the green pixels
were positive torque (helped the wheel move CW) and the red
pixels were negative torque. The actual shapes and orientations
of the curves are irrelevant. This is step 1. All that matters is
finding any configuration that has more green pixels than red.

And, YES, this particular program seems to find some.
But there are not very many configurations AND
the net positive torque is VERY small.

For many decades, very serious people have searched
for a way to keep a wheel rotating. They haven't seen it.
One legitimate excuse is that they are all looking straight at it and
still can't see it because the effect is too small to notice.

For me, this net positive torque, however small, is unexpected.
It is an anomaly. It should NOT be happening. It seems to
violate some assumptions concerning thermodynamics.

This could all be some subtle error in my equations/algorithms
in which case everything here is bogus. It is important to validate
all this and have other people look over the code I have posted.
I encourage other people to design and replicate their own
experiments.

In your posting, you mention that you have done something similar
involving "hundreds of scenarios". There are no details as to your
methodology so it is really hard to compare to what I have done.
My program currently evaluates about 15 configurations per second
when it is searching for something useful. For each configuration it will
compute the torque at one degree steps (360 total) and then sum
them all up for a figure of merit. It has elaborate rules for making
small random changes and evaluating the new configuration to see
if the changes are beneficial, etc. It can easily run for a minute or more
before it detects that no random changes seem beneficial anymore.
It then saves this result (only if it is positive torque) and automatically
starts with a new random configuration.

Several times I have run this all night (ten hours or so). This figures out
to be about half a million configurations evaluated...in just one night.
I have provided a link to allow anyone to download the program and
try this for themselves.

My only goal here is to work toward some validation that this
effect (net positive torque) is actually happening. Everything I have
done, the source code, the running program, all the technology
is downloadable or available. I am hanging around here to
answer questions and explain everything I have done.

No secrets. Nothing obscured. Just science.

[jim_mich]

Bill, I'm a very experienced Visual Basic programmer. You mention that your computer program increments in 1 degree steps. My guess is that the one degree steps is too big and it produces the small net positive torques that you are seeing. I've written many computer simulations and I always make the step angle variable so that I can adjust it. I've found that 0.25 step angle is about the biggest step value that will smooth the numbers enough. Of course this will slow down the program as it must do a lot more calculations. Sometime I've set up programs such that they run continuously while computing the average of many rotations and then use an odd step value like 0.251 so that each rotation of the wheel doesn't land in the same spots.

Look at it this way... If the point at which a string becomes taunt is between steps then the resultant calculation for that step can be off by almost one full degree.

Hope this helps.

[Bill_Mothershead]

I've found that 0.25 step angle is about the biggest step value that will smooth the numbers enough.
....computing the average of many rotations and then use an odd step value like 0.251 so that each rotation of the wheel doesn't land in the same spots.

Thanks for the post, Jim.

These are actually very good ideas.

I will work on the program tomorrow and post the results
of this experiment, whatever they may be.

Thanks again.

[Tinhead]

Interesting observations, couldn't help myself and had to run it through WM2D. WM2D showed me that the torque sum was negative, so I exported the meter data and evaluated it with one of those free graph packages.

You will see in the screenshot that it also calculates a negative area = negative torque. Tried a couple of different configurations, but the overall result was always negative. Let me know when you find a promising configuration, would love to double check it :)

Cheers,
Rainer

P.S. was not able to use your program, it was asking for some borland extension?

[Bill_Mothershead]

I've found that 0.25 step angle is about the biggest step value that will smooth the numbers enough.
....computing the average of many rotations and then use an odd step value like 0.251 so that each rotation of the wheel doesn't land in the same spots.

Jim....

Your insight is absolutely correct. Played with the code and have some insights.

I seem to remember from a calculus class several decades ago,
when doing stepwise integration, the smaller the slice size the more accurate the results.

I tried smaller slice sizes (less than a degree) and the numbers
do change. The number of revolutions, however, doesn't seem to
matter much, especially if the step size can evenly divide into 360.

After working on the code for a while, I came up with a compromise
(for now). I am running with .1 (one tenth a degree) steps for one revolution.

As expected, this kills the performance. Does about 1 or 2
configurations evaluated per second now so it is doing about 10 times
as many calls to get_torque( ) and running 1/10 slower.

After running it for a while, it is (slowly) finding configurations with
positive torque, though not as many and they look a little different
than what I was seeing. This probably is a result of not evaluating
enough configurations. I will adjust the "search time before giving up"
number and run it in auto mode all night to see how it does.

I summary, numbers are slightly different (hopefully more accurate)
and the program is still finding positive configurations.

[Bill_Mothershead]

Interesting observations, couldn't help myself and had to run it through WM2D. WM2D showed me that the torque sum was negative, so I exported the meter data and evaluated it with one of those free graph packages.

You will see in the screenshot that it also calculates a negative area = negative torque. Tried a couple of different configurations, but the overall result was always negative. Let me know when you find a promising configuration, would love to double check it :)

Cheers,
Rainer

P.S. was not able to use your program, it was asking for some borland extension?

Thanks for the post, Rainer.

Great stuff ... exactly what is needed now.

Here is an overview of how my program works.

1) Starts off by using a random number generator to assign values
to attach point coordinates and string lengths.
Calls code to get the configuration's merit.
This becomes the "old standard".
Zeros an elapsed timer.

2) Makes a copy of the old standard and then
makes some subtle, random changes.
Calls code to get the merit of this new configuration.

Compares the merits.
If the new one is better, it becomes the new "old standard"
and the timer is reset to zero elapsed seconds.
If not as good, then just ignores new stuff.
Either way, just loops around in step 2.

3) If the elapsed timer goes beyond (30 seconds?)
then it means that this configuration is not being improved.
It just records the configuration for later viewing/analysis.
Then starts over again with step 1.

The merit from step one, a random configuration, is almost
always negative or really, really small. It is not unusual for
random configurations to have some prohibited or disallowed
condition, such as the weight going so low that it is outside
the wheel or the strings can't reach = attach points too far
apart. The code detects a variety of things and reports a
large, unnatural torque which forces the merit to be negative.

The point here is that it is normal and natural for any random
configuration to be negative or useless. A really good
configuration is the result of a lot of automated "searching"
and such.

My program's coordinate system is just based on the
graphics I am using. In order to do the big GIF animations
I had to scale it down from 360x360 to 256x256.
I somewhat expect that my program isn't going to behave
like what you are using...which is ultimately good.
Any interesting coordinates+string lengths that my program
would find, would probably(?) not translate favorably.
That is just a guess; an expectation. My thought is
that if I said "use these string lengths and coordinates"
you would immediately plug them in to you simulation,
and, of course, it wouldn't work and you would be
justified in thinking this was all bullshit and just give up.

I am totally unfamiliar with your simulation program.
It looks like it has some really neat features.
It might be a little awkward, but perhaps you could
find a way to get it to do searches? Perhaps batch
processing? I am obviously clueless here.

One configuration you should probably test your
simulator on is the same thing I did with my first GIF.
Do one string on a weight. We know it will be
symmetrical and sum to zero (certainly not pos or neg).

My apologies about the non-working program. MY BAD!
Obviously need to find the right linker switch and
test this on a virgin machine. Will post when I
get a working version uploaded. Again, sorry.

[Tinhead]

I am totally unfamiliar with your simulation program.
It looks like it has some really neat features.
It might be a little awkward, but perhaps you could
find a way to get it to do searches? Perhaps batch
processing? I am obviously clueless here.

One configuration you should probably test your
simulator on is the same thing I did with my first GIF.
Do one string on a weight. We know it will be
symmetrical and sum to zero (certainly not pos or neg).

Yep, it is script driven and you can do batch processing. I used one of the included sample scripts ('optimize' for the ones that know WorkingModel) and run it through my lunch time break. The sample can only optimize one parameter at a time, but it already found something, see attached pictures.

Have to run it with a smaller more accurate step rate, but I was surprised that it found one configuration with positive outcome at all.

Cheers,
Rainer

[Tinhead]

P.S. the simulation was running with 10 RPM.
A little bit slower or faster and the result will turn negative again. The difference between our simulations is that in my one the weight shows a more realistic behaviour ( the swinging motion resulting from the gained momentum).

I guess somehow I was lucky in the above setup and hit a soft (resonant) spot.

Cheers,
Rainer

[Bill_Mothershead]

.... but I was surprised that it found one configuration with positive outcome at all.

I guess somehow I was lucky in the above setup and hit a soft (resonant) spot.

Cheers,
Rainer

A person, alone in the wilderness, who sees a flying saucer,
is somewhat justified in questioning his own sanity.

For this project, I think every day that it might end up
being some really stupid algebra mistake or misunderstanding
on how to calculate torque, or both, or something worse.

I am humbled that I have inspired Rainer enough to
put in some serious work to run his simulations.

Words can not express how relieved I am that he got
"lucky" and actually "found something".

Thank you Rainer.

Today is a very good day.

Thank you, all.

[Bill_Mothershead]

I found the linker switch and uploaded a tested
version of Bessler9.exe. Runs stand-alone
(doesn't give an error about a runtime DLL).

http://www.getnet.net/~moth/Bessler9.exe

Useful instructions... you can "drag" the
attach points of the strings, and the weight.
If you carefully put the cursor in the middle
of a string (not easy to get it exactly)
you can "drag" it up and down to change
string length. Click the MERIT button to
get a graph or use the scroll bar to roll the
wheel around 360.

For this version, I cut the time parameter
for "giving up" in the auto search mode
to a somewhat reasonable 20 seconds.

Last night, I ran it with the time parameter
set at 120 seconds. It found lots of good
configurations...but also some surprises.

The program records a "history" of the best
100 configurations, sorted by merit. I had
expected a large variety of configurations,
including at least a few where the frame attach
point was to the right of the axle. I know it finds
plenty of these kinds of configurations.

What I found in the history buffer was 100
clones of the last GIF on my web page (and
various variations on that theme.) They had
"crowded out" all other lesser-merit configurations
(especially the frame-right-side stuff).

OK. That is unexpected. Something is going on.
What does it mean? What is the program trying
to show us? Is this the hint of some kind of
pattern, or mechanical strategy leading to
the finding of an optimized configuration???

First some background. For my program,
by convention, I always have the wheel-string
attach point (at zero degrees) directly above the
axle. The search routines never uses random
numbers to change this X value, but it does change
the Y value to range from just under the wheel rim
to just near the axle (never below the axle for the
zero degree "starting point").

Sometime a few weeks ago I decided to limit this
Y value so it would not go closer than 10 pixels
from the axle. Can't remember exactly why I did this.
Sure enough, all the top 80 or so configurations
found last night were either 10 or 11 pixels from the
axle. Hmmm. And these were "evolved" from a
random starting Y number between 10 and 120.
Seems to want to be close to the axle. Obvious
experiment would be to change that artificial limit
of 10 to something smaller, like 5.

Another probable pattern is that the frame-attach-point
seemed to have an X value of about 10 less than the
axle. This varied a bit more, but I don't know why.

The general pattern was that, at the start, the wheel-string
is fully supporting the weight and the frame-string was slack.
The wheel would rotate CW into strong torque until the
wheel-string-attach-point was at about the 3:00 position.
Then frame-string becomes taut and pulls the weight to
the left until the frame fully supports the weight.
The wheel-string becomes slack at about 5:00 and the wheel
rotates without torque till about the 9:00 where it suddenly picks
up the full weight and hauls it back up to the starting point.

The graph between 9:00 o’clock and 3:00 is symmetrical.
The kinetic energy gained from 12:00 to 3:00 of having the
full weight pull down is EXACTLY the opposite of the
energy used to pull the weight up between 9:00 and 3:00.

But what is going on between 3:00 and 5:00???
Clearly the weight is between the two strings so it is pulling
on both strings. It is not much but it "looks" like positive
torque.

So if 9:00 to 3:00 is symmetrical and cancels itself out....
And 5:00 to 9:00 is nothing because the frame supports it...
What can we say about the forces between 3:00 and 5:00???
Do they accumulate, "unanswered"?
Is there nothing that "balances" them out?

Hmmm. Kinda burned out from writing so much.
This is a good place to stop and think about this for a while.

Anybody out there got a comment?

How about a reality check? Is this real?