Blood From Stone

[MrVibrating]

Hi MrVibrating,
I had build many versions of my construction.

You can see it under,
http://www.kuenstler-energie.de/index.php?id=9

There are 2 different outcomes when I compared the gear version with the chain version.

In the gear version their is no space to live, everything is 100 percent perfect

The chain version has this space to live, in the gaps of the chain.
The forces which appear were very strong and the chains are broken now.
You get a time difference between up and down.
This 2 mm gaps in the chain were enough to let the mechanism live, breath.

In my opinion: the chain version is a resonance version, dealing with gravity.

They're extremely impressive builds sir - your dedication to the cause is beyond doubt.. i could just never get any excess energy from such configs - like i say, even if net momentum can increase with RPM, it looks to me like input energy would also square up with RPM.

I could only recommend you obtain a copy of WM2D or some kind of dev environment with similar measurement capabilities; the maths could be entirely manual, using standard formulas - a basic 2D animator plus Notepad and Calculator... plus Google for looking up formulas - and you could produce a full energy accounting.

I'd love to help out, but just too busy right now to be of much service - my immediate priority is obviously getting to the bottom of last night's results; is it error, or does the concept of subsidising output CF with output GPE actually hold merit? Shouldn't take long to determine either way, but kind of got me hands full for now..

[MrVibrating]

Had a quick play around last night - i'm obviously not measuring the GPE / GKE properly yet..

The green weights begin and end each cycle at equal height - even at the half-cycle mark, as the OB weight reaches 90° horizontal, the other's lifted clear into the center, hence 1 kg has risen 1 meter and 1 kg has dropped 1 meter.. net change in GPE is zilcho..

Yet this doesn't take account of the GPE that was obviously converted to OB torque - and the system's obviously rotating because of OB torque, more than the CF work done (most of which is negative, not positive)..

After work tonight, if i get time, i'll try knock up another meter capable of taking an F*d integral - there's really no substitute (like Fletch says). Could try calculating the changing weight force as a function of angle and/or height, then adding this to the CF work integral, or else just reverting to sensing actuator force directly (via the constraintforce(#).x output), whilst keeping an eye out for any speed-related errors.. should be sufficient for resolving a single, slow cycle, which is all i need to get a handle on what's happening.

It's obviously gotta be a unity result - 'OU' from such a simple interaction seems frankly preposterous doesn't it? Should have it sorted by the w/e, then i can start testing the results of applying the red 'vMoI' masses...

[silent]

.

[MrVibrating]

@silent, will check it out later, thx mate..

Right, potentially significant progress last night:

- i know no one's interested in taking data right now, but for posterity; try making an F*V-over-time meter for the actuators, but using max freq for the period, plus max no. of integration steps per frame (9999) - this is an over-nighter, but worth the results..


- consider that the CF integral for the first cycle's ~7.5 J positive - a conversion of GPE into PE

- the input work against gravity cannot be less than ~19.63 J (GPE's path-invariant, time-invariant etc.)

- so net input energy's basically the latter minus the former - just over 12 J

- but net KE after this first cycle's only ~9 J

- where'd the rest of the input energy go?

- it was work done against gravity!

- we have an effective dynamic GPE asymmetry - less work has been output by the field, than input!

- it's lossy for now, but what happens when we cycle up?

- i left a 4-rotation sim running overnight, with both green actuators enabled, so 8 cycles (2 per rotation) - net input energy's now less than the system KE! OU!


So, all very preliminary for now, need to pick thru the results much more gradually, one cycle at a time...

..but just the basic picture illustrated by that first cycle - a non-dissipiative (ie. non-entropic, non-thermodynamic) loss, plainly due to more input F*d than output.. around 65% efficiency..

..realising this, i figured doing the super-HQ overnight run would either sharpen up that 65% result... or else, it'll change and develop over multiple cycles...

Gotta go work now but the current results are "OU". I/O efficiency starts lossy and rapidly progresses into gain territory.

Such a simple interaction. Elementary, even. Fascinating results tho, from the 1st cycle onwards..

[silent]

.

[MrVibrating]

Damn, think i've sussed it.. pretty much to unity. There's currently about half a Joule excess left, however i found i could crank up the accuracy slightly higher - 10,000 integration steps per frame, times 32765 frames - gonna take 6 hours or so to run... seems kinda pointless tho:

• Net RotKE rises by ~ 8.11 J per cycle

• Accordingly, after 8 cycs, RotKE is 65.13 J - pretty close to unity

• Net KE (rot + radial) is 97.7 J

• 97.7 / 8 cycs = 12.2125 - that's our per-cycle input energy to the actuators

• 19.6133 J of GPE is input each cycle via the radial lift

• That 19.6133 J lift is accomplished using just 12.2125 J of input energy to the actuators each cycle

• 19.6133 - 12.2125 = 7.4008 J must be the average output CF work subsidy per cycle - caused by the OB weight

• The independently calculated per-cycle CF input work does indeed average to that same value - about 7.3 - 7.5 J p/c


So, this is what unity looks like folks.. :|

Which was basically all that was initially expected to happen..

Panic over, i think..!

So, now we can start rolling out those red masses, to see if we can't maintain the p/c momentum yield, by preventing the RPM's from climbing over successive cycles...

The objective is constant p/c input energy, for constant p/c momentum, even if only across a small, limited RPM range..

[MrVibrating]

...still unable to solve for the last half Joule or so, so not going to give up on that until it's down to mJ's.

Plus, there's another slight weirdness i can't get straight yet:

• the per-cycle input energy is the GPE (19.613 J), minus the net output CF workload (7.29 J)

So however high the RPM's get, and thus whatever the absolute input and output CF workloads, their difference is always 7.29 J positive per cycle, so every radial lift is always subsidised by 7.29 J of output CF work from the currently-falling other weight. Go that?

Thus input energy per cycle is always 19.613 J - 7.29 J = 12.323 J, right?

However, the per-cycle rise in rotKE is only 8.1 J... so, where's the rest of that input energy going?

It gets stranger - when both green actuators are active, one's always starting to lift at BDC as the other's finishing up at TDC. Thus radial KE never has a chance to go to zero during a run.

And the sum of rotKE plus that ever-present radial KE is equal (to within a half Joule, anyway) to the 12.323 J p/c input energy.

The problem is, p/c input energy's the same 12.323 J, even when only one actuator's active - and thus, when radial KE goes to zero for 180° of every rotation..

..during that time, net KE is just the 8.1 J per-cycle rise in rotKE.. so, where's the rest of the input energy gone?

Ie. for four cycles, 4 * 8.1 = 32.4 J of 'net' KE during that radial-KE-free 180° of rotation, yet input energy is 4 * 12.323 = 49.292 J.. see what i mean? That difference won't resolve until the next radial lift kicks in at BDC..

So, not quite done here yet..

[Fletcher]

Hi Mr V .. I know you don't often read other threads but here is a sim I once made that physically has some similarities to what you are exploring.

The radius shift isn't along radials and you will see why when you run the sim. It does use springs for restitution.

Maybe it will be of some use to you in planning your future devices.

Have a good xmas.

[MrVibrating]

OK i've added 3 more meters:

"Weight 2 Actuator F*V" (times time)

This is a good measure of work done, when it isn't creating or destroying energy, but it only does that when subjected to high and abrupt accels / decels, and these errors can be spotted and weeded out.

In short, it's pretty fool-proof, if not idiot-proof (looks away humming).



"Weight 2 CF/CP Work Done" (CF*V times time)

This just isolates the equation for the single active actuator - the initial meter combines both green weights, then both reds, then their net sum, but to eliminate the possibility of interference, here's the proof... (plus it's easier to take data from, having only 2 columns).



"Weight 2 Actuator F*d" (time-invariant)

This is a standard F*d meter - it multiplies the force 'felt' by the actuator, by its 1 meter radial displacement.

As noted already, we can't use this type of meter for an oscillating action, since it'll curve back on itself forming closed loops if we allow the actuator to switch direction, ruining the line integral (the area under the curve).

However for a single stroke in either direction, it's perfectly fine!

This means we can use it to sim each stroke independently, adjusting the graphing direction between sims when the actuator changes direction.




So, to be able to make any use at all from the new F*d meter, we have to break each cycle down into two strokes - the lift into the center from BDC, and then the lift from center up to TDC.

As such, here's the first 90° of a cycle, still using a ¼ J kickstart, at a fixed integration step of 1 per frame (i've found that using thousands just gives mixed results, besides making runtimes unmanageable):


(believe it or not, this is sped up - you've never seen paint dry so fast!)


Here's the integrals:


Weight 2 Actuator F*V*t = 8.35572394 J

Weight 2 CF/CP Work Done = -0.653315247 J

Weight 2 Actuator F*d = 8.354699198 J


Are you getting this? I'm struggling with it, me..

The CF work integral checks out - it's solid.

This is work done against CF force, by the same actuator performing the radial lift.

The radial lift that raises 9.80665 J of GPE.

Plus that CF work.

So, 9.80665 + 0.653315247 = 10.459965247 J.

10.459965247 J of work has been performed by that actuator.

That CF work was definitely done..

..and that GPE was definitely lifted.

10.459965247 J of work, in total.

For 8.35 J of input energy.

We also have 8.6 J of KE.

We began with ¼ J, so:

8.6 - 0.25 = 8.35 J is the actual rise in KE.

So it's a unity result, here at the halfway mark...

..except, once again, it is the manner in which unity is being attained that is interesting - how in the hell does 8.35 J perform 10.45 J of work?

Because that 10.45 J of work was definitively done!

GPE is time-invariant and not path-dependent. It's G*m*h, period. 9.80665 J of work was definitely done by the actuator!

Plus it did another 0.65 J of work against CF!

That's 10.45 J of work, is it not? It's not 8.35. Never 8.35. How can 8.35 be 10.45? They're two completely different numbers! Even i know that.


But, if we've really only spent 8.35 J doing it, then... umm.. it's still 9.80665 J of GPE, right? And it's just sitting there.. sooo.. what if it were to fall..?

Halfway into the cycle here, we might just have stumbled across something exciting..

[MrVibrating]

Hi Mr V .. I know you don't often read other threads but here is a sim I once made that physically has some similarities to what you are exploring.

The radius shift isn't along radials and you will see why when you run the sim. It does use springs for restitution.

Maybe it will be of some use to you in planning your future devices.

Have a good xmas.

Brilliant work there mate, will need to take some time to study it properly - it's obviously mechanically closer to whatever B. was doing than what i'm currently up to, but i'm still in data acquisition mode, will snap out of it and try an actual mechanism as soon as i find anything worthwhile.. next year, hopefully..

B's clue about weight's "attempting to find equilibrium" is not one i've previously given much thought to, but it's a good angle of attack..

Re. radial vs angular translations - i've settled on the former specifically in order to eliminate the related angular components - i'm interested in the 'inertial torque' aspects, whereas curved trajectories mix in angular momenta, muddying the waters, or at least, skewing my blinkers.

Which is not to presume that such angular components aren't equally useful or even vital to success - i'm just 'compartmentalising' for now..

Hope you have a great Christmas too (and everyone else)!

[MrVibrating]

So, regarding this tantalising F*d result..

..if we have to drop 9.81 J to raise 9.81 J..

..and we have to spend 8.35 J to raise 8.35 J of KE..

..then there's obviously nothing to get 'excited' about..

..except that 8.35 J did 10.45 J of work.

It's as if 'unity' is somehow dependent on a miracle?


It's a unity result... dependent on a paradox!!!

There can be no paradoxes!!!!

Only failings in comprehension.. surely?

So what am i missing - what 'context' could possibly excuse 8.35 J completing 10.45 J of work?

The fact that we only got 8.35 J of KE rise almost seems incidental - it's almost as if CoE has started breaking itself in order to maintain a 'unity' outcome..

What dastardly magic is this?

[MrVibrating]

It's reminiscent of this result:



Here, we see a motor perform a 1.5 J rise in rotKE, using only ½ J of input energy - so, 3x OU..

..or it would be, but for the work done against CF. However, that CF workload merely cancelled the counter-torque from the motor - so all of the actual angular acceleration - all the torque that did work - was performed solely by that motor, using just half a Joule..


We can glimpse a similar kind of "OU performance" when using a gravitating weight as a 'stator' to torque a rotor against. There, again, the work done by the actuator / motor or whatever would be OU, but for the GPE output..

In all these types of systems, it's not the unity result that's interesting, so much as the way in which CoE is enforced - you can have OU performance.. only, you have to pay for it; net result, unity.

Yet it confirms that over-unity performances are possible!

Here, unity depends upon an OU efficiency!

So, we know such beasts can exist.. which brings us a step closer to baggin' one on the sly, with any luck. Softly softly, eh..

[MrVibrating]

OK it's not 10.45 J of work - the actuator F*V*t and F*d metrics include CF force and gravity, so they don't need adding back together... Sorry, it was late..


What it means however is to find the actual work performed against gravity, we need to subtract the work done against CF, right?

So the actuator did a total of 8.35 J of work..

..of that, 0.65 J was work against CF, so:

• 8.35 - 0.65 = 7.7 J was the actual work done against gravity!



So the actuator only did 7.7 J of work, to raise 9.81 J of GPE!


Likewise however, 'weight 1', rotating downwards, must only have done 7.7 J of output work..

In other words, of the 9.81 J drop in 'OB GPE', only 7.7 J of it actually converted to rotKE:

• 7.7 J came from GPE

• 0.65 J came from 'inertial torque' - work done against CF

• 0.25 J was the starting KE

• 7.7 + 0.65 + 0.25 = 8.6 J rot (& net) KE

So the reason we were able to raise 9.81 J of GPE using only 7.7 J of input energy, is that only 7.7 J of ouput energy was converted to KE by the 9.81 J OB GPE output..

So the question of whether or not we're looking at a potential exploit, depends upon the conditions of that coupling, right?

In short, how & why do the factors limiting the conversion of OB GPE into rotKE likewise constrain the input F*d integral?

IOW, what might be the options for 'gaming' that relationship?

How does the input efficiency 'know about' the output efficiency?

Could we effect that same condition by some other means?

• We're looking square at an interaction that raises 9.81 J of GPE, using only 7.7 J of input work.

• remember, we already know how to change GPE without even incurring any CF work at all, positive or negative

Likewise, tho, we could arrange for any arbitrary CF work to accompany a GPE change - the point is, we know how to decouple the two workloads, and they can be rendered completely independently, purely by controlling radial speeds (as demo'd earlier).

So, what is the functional effect of the OB weight in this relationship?

Answer: it simply applies an angular acceleration.

The actuator doesn't 'know' anything about its OB partner - it cares not why there's angular acceleration... only that there is..

The only property distinguishing 'OB torque' from any other kind of torque, is that it's reactionless - if we instead tried using a motor to apply that angular acceleration, we'd also necessarily be raising counter-momentum.

Hard to see how that would further our cause, tho..

So, how does the actuator 'know' that the OB GPE is only worth 7.7 J?


I mean, if we can raise 9.81 J of GPE using only 7.7 J of work, but only when we also have 9.81 J of GPE converting into 7.7 J of OB rotKE, then how does condition A 'know about' condition B?

Is there a potential exploit there?

[MrVibrating]

The other angle to meditate upon, is the question of precisely how - mechanically - this advantage is manifested in the actuator F*d integral:

• it appears to challenge path-independence!

We know, unequivocally, that GPE is simply GMH; The work done, raising 1 kg by 1 meter, HAS TO BE 9.81 J.

The meters are directly recording the instantaneous forces and displacements acting on the actuator..

..yet their product - including work against CF - is only 8.35 J..

..yet 9.81 J of GPE has been raised!


Now, if the CF force was working with us, rather than against us, then it would be partially subsidising the work required to lift the weight.

Then, our input energy would be the remainder of work that wasn't converted from output CF work.

However here, it is input CF work. Adding to the work done against gravity!

It's an additional load, a further input of work.. not an output!

So, regardless of whatever the OB weight's doing as it rotates downwards, how in the hell is 8.35 J of work raising 9.81 J of GPE?

It's a paradox!!!

There cannot be a paradox!!!!

Am i tripping?

WTAF? :|

[silent]

.