Decoupling Per-Cycle Momemtum Yields From RPM

[WaltzCee]

Just tapped into google and the end momentum K.E. is around 9 J.
So if it actually costs ½ Joules to get 9 J then you have arrived.

Google uses as much energy as the entire City of San Francisco. If we could tap into the
energy of their hot chips, we wouldn't need a perpetual motion machine.

[Senax]

...
And incidentally, applying neologisms to reference commonly-understood terms adds nothing to their comprehension, and is not the mark of 'earnest science'..

Well Stafford Beer said that it's all a question of using the right language and
I agree with him.

You're not alone in objecting to my use of Ersatz Gravity. I have probably
annoyed most of the forum by it, Ralph especially.
But new wine needs new bottles and I have found it incredibly useful.

In particular it has drawn my attention to the difference between lifting a
weight in EG, lifting a weight in NG, and the falling stick phenomena which
Georg recently referred to.

If Bessler let his lead beads slide down a wheel spoke then he gives them
an acceleration greater than that due to gravity. Strain energy is brought
into play.

Soz but when i see common concepts being reworded for no apparent benefit it just says to me "this ain't someone who's measuring shit", and probably not even wearing a bra on his head...

I've experimented replacing gravity with CF force - happy to re-post the sims - and found that it is impossible to gain momentum from CF force as we can with gravity - any gain in momentum on one part comes at expense of that of another / the main axis, hence the net system momentum cannot be altered via the internal expenditure of work, per N3.

To put it another way, 'kiiking' under CF force is physically impossible - any momentum you gain, the rotating system loses.

I would be totally on for a case of beer / wine if proven wrong here, since the implications would be truly awesome, but i'm pretty sure it's a non-starter..

The difference with gravity is that it's a uniform constant acceleration, and doesn't change significantly with height (at our scales), unlike CF force / radius.

The real magic CF force brings to the mix lies with the reactionless nature of inertial torques - hence a 'rotor' can be sped up or slowed down without counter-torquing a 'stator', and hence without incurring counter-momenta; this alone is the special condition that allows a kiiker to vary the relative time periods of the 'rising' vs 'falling' phases of the swing; that is, the 'time-spent-gravitating', and thus exchanging momentum with gravity (being accelerated or decelerated by it), 'up' vs 'down'..

..an actually useful neologism here might be 'G-time' as a short-hand for 'time spent gravitating' - if the 'up' swing has a longer period than the 'down' swing then it has 'negative G-time' and loses momentum, vice-versa and it's positive, with gain.

But 'CF-time' doesn't abstract the same way - it makes no difference how fast or slow the 'up' vs 'down' legs are, the loss of net system momentum is equal to the increase in 'swinging' momentum, instantaneously, conserving net angular momentum.

CF force is 'momentum-conservative'.

Gravity is not..!

If the space traveller lifts a weight along a radial spoke and it is also allowed to fall along a radial spoke (or not) then more than CF is involved.

[MrVibrating]

OK i went back to the very first sim in this thread - the penduwheel - and made some refinements:

• the brake remains locked for ¾ of each cycle, the motor only activating through a 90° arc as the weight drops below the horizontal (y=0) mark

• the motor applies torque until the input target relative velocity has been reached; accelerating the wheel, whilst decelerating the gravitating weight

• the amount of torque applied is multiplied up by the rising system speed, to compensate the diminishing G-time per cycle

• hence the target relative speed (currently set at 10 rad/s) is always reached, well before the weight reaches BDC and runs out of G-time, regardless of rising RPM

The system's immediately showing OU.. not as KE rise, but as the net of KE rise plus energy dissipated by the brake...

The form of 'brake' used is a rotary damper, set to 5k N-m-s/rad, and metered for torque * angle.

Additionally, the KE being dissipated each cycle is totted up on a per-cycle basis, by noting the system KE immediately before and after applying the brake - which would seem a foolproof metric, yet sums to an even greater OU efficiency.. each 'collision' here dissipates 25 J per cycle, and there's ten cycles, implying 250 J of heat has been produced; 17 J more than the brake's torque * angle integral..

I'll attach the sim below - you can safely reduce the accuracy if not taking data and wanna speed it up.. will post a GIF anim tomoz or ASAP, spreadsheets too. Below is a cut'n'paste of results from the enclosed run:

__

Brake T*a = 232.863954 J

Motor T*a = 258.3346776 J

Motor T*w*t = 258.1637199 J


258.3346776 - 232.863954 = 25.4707236 J of mech work should remain;


Initial KE = 96.1704 J

Final KE = 151.9670 J

Rise = 55.7966 J


55.7966 / 25.4707236 = 2.2 or 220% more KE than has been paid for..


OK, check KE before and after braking each cycle:

Code: Select all

cyc#	before			after		dissipated

1)	147.4229 J		122.4262 J	24.9967 J
2)	153.7293 J		128.7293 J	25 J
3)	159.7556 J		134.7588 J	24.9968 J
4)	165.5408 J		140.5404 J	25.0004 J
5)	171.1174 J		146.1163 J	25.0011 J
6)	176.5079 J		151.5076 J	25.0003 J
7)	181.7351 J		156.7343 J	25.0008 J
8)	186.8150 J		161.8128 J	25.0022 J
9)	191.7581 J		166.7579 J	25.0002 J
10)	196.5836 J		171.5805 J	25.0031 J

Total dissipated in 'collisions' = 250.0016 J

Brake has burned 250.0016 - 232.863954 = 17.137646 J more energy than accounted for by its torque * angle..

System ends with:

Input = 258.3346776 J, motor torque * angle

Output = 55.7966 J of KE rise, plus (taking brake T*a as the more conservative measure) 232.863954 J of heat, for a total output energy of 288.660554 J

Net efficiency is thus 258.3346776 J in, for 288.660554 J out = 1.1173898.

111%, basically.

So where's that come from then, eh..?

[MrVibrating]

Here's the anim:




...simplest concept; it's just an accelerate-and-brake cycle between two equal inertias, one of which is also gravitating.

This is generating 111% more 'net of heat + KE' than 'input torque * angle' supplied to the motor..

[MrVibrating]

..so the basic hypothesis seems confirmed; you can substitute increasing torque over decreasing angle to compensate for the decreasing 'time-spent-gravitating' per cycle as RPM's rise, thus maintaining per-cycle momentum yields over and above what would otherwise be possible.

The 'momentum yield' here isn't a 100% cancellation of counter-momentum, just the rising vs falling G-time differential, caused by the motor impulses delaying the descent, relative to the 'locked' ascent.

Hmm.. i wonder what would happen if the 'target speed' is changed from 'relative', to absolute..? So for instance the motor would keep applying as much torque as necessary to accelerate the wheel by say 1 rad/s per cycle, absolute (relative to coordinate space), before the brake engaged.. might be interesting to compare..

[MrVibrating]

..running a higher-quality (slooow) version of the last sim ATM.. will post results when ready..

..meantime tho, the obvious question would be, if this result is real, and the dissipated KE makes up the greater part of the gain margin, then could it be harnessed some other way, besides dissipation / heat generation?

For example, could the braking be accomplished by loading a rotary spring, instead of the friction brake..? Then the KE 'losses' would be neatly recouped as sprung PE. It still accomplishes the primary objective of equalising the velocity difference - so no change to the momentum distributions - and just collects the KE difference instead of dissipating it...

Likewise, how about raising a weight instead? IE. the question then is, can you brake away the speed difference between two masses by causing them to raise a third mass..? Presumably this is feasible, too... Then each 'collision' stroke could directly raise an over-balancing weight..


First thing tho is to suss out whether it's real or not.. if so then it should be fairly simple to identify and confirm the gain conditions..

[MrVibrating]

Right, re-ran the sim at 10,000 integration steps / frame, and refined the input energy figure - the integral of force * velocity * time has pretty much converged with that of torque * angle:



Motor T*w*t = 261.4607647 J

Motor T*a = 261.5542733 J

..so it seems plausible that 261.5 J of input work has been performed during the run.. (anyone disagree?)

The T*a integral for the brake however appears to be in error:

Brake T*a = 466.3682955 J

So a big increase has been caused by raising the number of integration steps per frame. This is confirmed by re-running the sim at just 10 i-s/f:

Brake T*a = 14.83823855 J

..so, bollocks to taking T*a plots from rotational dampers - you'd think it was the most logical way to construct a brake, but they produce crap data, apparently..

Still works mechanically as a brake tho - remember, all it's there for is to accomplish an 'inelastic collision' - that is, equalising the speed of the two co-rotating parts, redistributing their momentum by speeding one up, at the expense of slowing the other down. Net momentum's conserved, and the two parts can thus begin the next cycle relatively stationary to one another, and so beginning at the bottom of the 'V²' multiplier on the energy cost of accumulating momentum..

..besides, 'two checks on everything', right? We don't need no stinkin' T*a integral just to confirm what we've already plainly seen in the KE plot - each collision dissipates 25 J precisely!

And, there's ten of them, in consecutive sequence..

..10 * 25 J = 250 J, does it not? Ie. each collision reduced the system KE by 25 J, and there were ten of them, so.. seems pretty unequivocal that 250 J of heat must've been produced..

..unless, this form of KE loss is actually non-dissipative; a 'non-dissipative' mechanical energy loss is the inverse of a gain - arse end of the same phenomenon - but friction brakes are the quintessential essence of 'dissipative' loss mechanisms - there's no question brakes get hot, type situation, so... umm... nope sorry, i can't see a way out, here..

The system definitely produced 250 J of heat...


...plus a final KE of 151.9775 J, up from an initial float of 96.1704 J - an increase of 55.8071 J...

..so total system energy rise was 305.8071 J. That's how much work was done.

By 261.5 J of input energy.

305.8 / 261.5 = 1.17x unity.

No change in GPE.

This looks real..

..as in, if you wanted a free-energy thermal plant, able to power itself whilst providing constant output power... you could totally have one right now (i hereby christen it 'B-cat', all rights reserved etc.)..

Shouldn't be too hard to capture the same gain in the form of sprung PE rather than friction heating, tho.. likewise, maybe applying a 'generator' in place of the brake - should do the same job mechanically, conserving the net momentum, whilst producing a clean T*a integral, and directly recouping the 25 J per cycle..


If it is real, then the primary gain condition has to be divergence of the motor's inertial frame, and the gain will be directly proportionate to the net momentum increase - ie. from cheating the V² multiplier on the input-energy cost of accumulating that momentum.

The most obvious starting point here would seem to be to take hi-res sims of the sequence one, single, cycle at a time, to see if the input work / energy is indeed constant per cycle, and to check this per-cycle input energy against the per-cycle KE rise.. does the 44.3 J gain accumulate at equal increments per cycle, or are they increasing with system velocity?

[MrVibrating]

Target relative speed lowered 10x to 1 rad/s:

i-s/f = 100
final KE = 100.8689 J
initial KE = 96.1704 J
KE Rise = 4.6985 J

KE dissipated per cycle = 0.25 J, * 10 cycs hence 2.5 J in total

net system energy rise thus 4.6985 + 2.5 = 7.1985 J

input T*a integral = 2.626059565 J


7.1985 / 2.6260 = 2.7412, or 274%

So reducing the 'bitesize' by a factor of ten has more than doubled the efficiency - to the extent that the KE rise alone is now almost twice the input energy:

4.6985 / 2.626059565 = 1.7891, or 179%

..the quarter-joule wasted each cycle is for the birds, now..

This does seem consistent with predictions of lower-displacement interactions reaching greater OU efficiencies..

..will have to try raising the target relative speed by a factor of ten, next.. results to follow..

[MrVibrating]

OK, TRS = 100 rad/s might've been a bit ambitious - turns out it'd cause the pendulum to begin fully-counter-rotating, which in principle would be fine, except for the fact that the motor's control conditions depend on the bob being in that lower quadrant, so as soon as it reverses back out of it, the motor deactivates.. and so rather than spend hours redesigning the code i've instead pushed it as far as it'll go as-is:


Target relative speed doubled to 20 rad/s:

i-s/f = 100 (freq maxed in all these runs)
final KE = 252.7135 J
initial KE = 96.1704 J
KE Rise = 156.5431 J

KE dissipated per cycle = 100 J, * 10 cycs hence 1 kJ in total

net system energy rise thus 156.5606 + 1 kJ = 1,156.5431 J

input T*a integral = 1021.620457 J

Efficiency thus:

1,156.5431 / 1021.620457 = 1.1321, or 113%


So a significant drop in efficiency has been caused by doubling the displacement of the inertial interaction - the input energy is much greater than the KE rise, and the net of KE rise + heat is just 113% of unity.


The previous result of 274% for a TRS of 1 rad/s - with 179% on KE gain alone - is thus the new benchmark.. obviating the need for regen braking entirely (tho i still might have a crack at it - whole 'nother 95% up for grabs, there)..

First off tho, should probably break down that TRS=1 result one cycle at a time, stretching each one over all available memory, with the end conditions of each forming the starting conditions of the next. This should enable precise identification of the gain dynamics..

[MrVibrating]

..i've now begun testing single cycles. Initial results show that the very first cycle is around 170 to 180 % efficient - this is at 100 integration steps / frame.. now waiting for a 10,000 i-s/f to finish (gonna be hours), which should put an exact figure on the efficiency of that first cycle.

Will then continue likewise for successive cycles, picking up wherever the previous one left off.

Can't help noticing the obvious tho - it looks like for TRS=1, each and every cycle is precisely 179% efficient - just in terms of conversion of input work (torque * angle) into kinetic energy, and ignoring the further output energy being dissipated as heat loss..

This 10k i-s/f run should be completed by the time i get in from work later tonight, and i fully expect the motor P*t and T*a integrals to resolve down to millijoules, if not microjoules, at that 179% figure. Just for the PE to KE efficiency alone.

If each interaction is indeed precisely 179% OU, then the only possible interpretation is that the motor's inertial frame is indeed diverging, but on a per-cycle basis - that is, the divergence is not accumulating over successive cycles, which was (and remains) the ultimate design objective, if possible...

..i say 'if' as it's no longer certain that it needs be - i've only previously considered gain scenarios wherein the momentum divergence - and thus input / output efficiency - evolves over successive cycles.. but here, it would appear that it can be accomplished satisfactorily in a single cycle, for a constant per-cycle efficiency over a rising RPM..

..if this is indeed the case, then we can begin thinking about immediately raising more GPE than has been dropped..



It's been a circuitous route, and taken all bleedin' year, just to fix the perfectly-good sim i started out with - two equal inertias, one of which is gravitating, that's all you need! - but it appears the thread topic's finally reaching some kind of solution..

[MrVibrating]

Righto, here's the results of a single cycle at psychotic accuracy:


freq = 32,765 frames / 0.6177 secs

i-s/f = 10,000

initial KE = 96.1704

final KE = 96.6448

KE rise = 0.4744 J

motor T*a = 0.354284055 J

motor P*t = 0.35475147 J

..let's take the average there:

(0.354284055 + 0.35475147) / 2 = 0.3545177625

..call it 0.3545 J.

0.4744 KE rise / 0.3545 input energy = 1.3382x unity, with respect to KE alone (not incl. heat losses).

For the latter, the KE post-braking was 116.5088 J, and 116.2588 after, so precisely ¼ J was burned off.

Hence the total efficiency for the first cycle (net of heat plus KE) is:

0.4744 J + 0.25 J = 0.7244 J total output energy

..and:


0.7244 / 0.3545 = 2.0434... basically 200% over unity.

..so that is jolly nice - dunno 'bout you but i'm celebrating with a lil' bottle of scotch here..

Overnight i'll be running cycle #2 at the same 10k i-s/f, max freq; if i'm up early enough a.m. i'll post results before work, and set up cyc #3 to run during the day, for results in the evening..


Before i forget - one final number central to all this:

• initial net momentum = 19.6133 kg-m²-rad/s

• final net momentum = 19.6616 kg-m²-rad/s

..so just a 0.0483 kg-m²-rad/s rise - absolutely fuck-all momentum rise carries over to cycle #2..

..i'll be keeping tabs on this over successive cycles but apparently the gain condition is isolated to each individual power stroke, not accumulating between successive ones.. dunno if this is just a current design inefficiency (the momentum gain's non-zero, after all) - maybe each cycle in Bessler's wheels was a one-shot deal, independently OU in its own right, yet in most (if not all) of the scenarios i've ran predictions for, the KE gain was a function of the accumulating excess per-cycle momentum - which in turn, is a function of the relative 'up' vs 'down' periods relative to gravity's constant acceleration..

..but how can the present 130% result (or 200% incl. heat) be explained in terms of a 0.05 kg-m²-rad/s momentum rise? It's surely waaay too much energy gain for such a paltry rise in net system velocity..?

So, currently it seems a bit inexplicable - yet if real, then it can only be resolved in terms of accelerating reference frames.. so it'll have to be happening during the power stroke, somehow.. that 90° arc from 9 o' clock down to 6 o' clock is somehow a lil' stretch of self-contained magic - an asymmetric inertial interaction and consequent KE gain, in one fell swoop.. The KE gain must've already been there at 6 o' clock..



TL;DR

At cyc #1 we're currently 133% efficient as regards input PE to output KE, and fully 200% if including generated heat, consistently to four zeros, at max-possible simulation precision. Cyc #2 and #3 to follow..


Good times.. :)

[justsomeone]

I am awaiting ME's response. 😎

[MrVibrating]

For anyone wishing to try replicate, the design brief, in a nutshell, is simply this:

• use a gravitating weight as a 'stator' against which to torque a rotor

• give the weight equal angular inertia to the rotor, about a shared axis

• apply an equal relative acceleration each cycle, before locking the two parts together at 6 o' clock and coasting back up

• give the system a good starting KE (the predicted gain condition depends upon already being in motion)

..whilst logging input vs output energies.


Alternatively, one could view it as a chain of accelerate-and-brake cycles between two equal, coaxial, angular inertias, one of which is also a 'weight'.



Again, the only substantive difference between this sim and the very first one on page 1 is that previously, the motor was controlled to only apply enough torque to hold the pendulum's rate of descent constant each cycle, and the amount of momentum that could thus be raised in the rotor each cycle was decreasing with rising RPM..

..whereas now, i don't care about the pendulum's rate of descent, so much as the constancy of the relative speed difference between the two parts across a range of RPM.. so if i set a 'target relative speed' of 1 rad/s, then this will always be achieved every cycle; it doesn't get smaller every cycle. Part of the trick here is only using a small part of the available cycle time from the outset, which makes it more practical to maintain that margin as RPM's increase; smaller relative accelerations = greater OU efficiency. Again tho, i've also set the torque to increase as a function of system velocity, so rising torque will more than compensate decreasing time-spent-gravitating per cycle.

So it's basically just a motor that uses a transiently-gravitating weight as a 'stator', before locking to it and repeating the cycle, and controlled to always attain the same relative internal acceleration each cycle, regardless of net system RPM.

That's the design criteria, and it appears to break PE to KE symmetry..

All other simmers here should be able to replicate this.. the most laborious parts are designing the triggering conditions - altho you could just circumvent all that by sequencing all the actions to timestamps, tweaking the timing each cycle to maintain the relative acceleration.. you don't need to apply logical operators (they really, really help tho) - and cutting & pasting the data into the spreadsheet to get the integrals.. the actual mechanism - as you can see from the anims - is simplicity itself; just pull a 1 rad/s relative accel (or whatever), then grab the anchors, coast back 'round and repeat, measuring the input energy, KE lost to the braking phase, and the KE rise..


I still have that ever-present self-doubt - it's a year-old sim; maybe i left a hidden motor there for some long-forgotten reason (jk - just double-checked) - but that's just the kind of idiotic mistake i'd make.. caveat emptor, as usual..

..if it is real tho, then it'll be pinned down to specifics - specifically, momentum-frame divergence, type stuff ('cos that's the only context in which a PE to KE gain is even hypothetically consistent).. and so 'going definitive' will mean identifying the precise gain conditions, to the extent that a desired gain can be plotted out from first principles..

So far, it looks good. Bit of an unexpected twist in the way it's presenting (on a per-cycle, rather than cumulative, basis), but that just adds to the excitement of 'discovery'..

[ME]

I am awaiting ME's response. 😎

Oh actually, I wasn't.
Do you think it's really necessary?
What do you think I would find?
What is your suspicion?
How should my response look like?


Anywho, to skip the vagueness and still keep it vague...
A meaningful response would mean for me that I have to wade through his current ramblings and see what kind of mathematical mistake he made this time.
Yet it's hard to argue on the specifics, when he treats mathematics as a slot-machine and plugs values into this KE formula he found without knowing why and how while he keeps being amazed that his so-called "cost of momentum" (units: m/s) magically causes a continuous rise in momentum when he replugs it (as-if units: Joules) per iteration. So let's not.

At least mrVibrating used to agree that there's a need of finding a loophole/exception in the physics formulas. Maybe this is that missing kink?
After him finding so many instances of clear overunity situations (Currently 133% after one cycle) then it seems, for himself at least, that he found something beyond the shadow of doubt... unless he's not sure? What do you think?

As I normally would, I could investigate and show what I think would be the normally expected mathematical outcome of the current phenomena.
And of course that should not match what he found. That's is actually the whole point. (mr Silent had me put on ignore because he doesn't understand that point)
Such should emphasize where a discovery breaks the laws of physics, and thus underlines the importance of the discovery, and maybe how to simplify a test.... or otherwise just show how the discovery is mistaken.
And all because a phenomena simply follows its own intrinsic behavior, and not some physics law because its written. But a simulator should follow the physics laws as written, unless the simulator uses different ones.
That's my angle at it anyway. Weird behavior of a probably new phenomena is what we try to discover.

mrVibrating had also me put on his ignore list, So I guess this "help" is likely not appreciated. Thus there's no point to work this all out. Especially when he explores something completely different in the next week.
I think that when he's so convinced about his overunity findings, that he should pick the simplest design and start building it. Otherwise, IMO, he only keeps battling with his simulator (and mathematics) and only find exploits there, but that's OK too.
He should be able to afford some losses with a not-so-perfect physical build as he only has to make it 101% efficient to still make it accelerate.

At least I'm glad that he saw the light too and now also uses Unicode [ link :-) ] to make the formula's look a tiny bit more readable.

[MrVibrating]

cyc #2:


freq = 32765 / 0.6163

i-s/f = 10,000

initial KE = 96.6448 J

final KE = 97.1182 J

KE rise = 0.4734 J

motor T*a = 0.360690495 J

motor P*t = 0.3683771 J

initial net momentum = 9.8308 kg-m²-rad/s

final net momentum = 9.8549 kg-m²-rad/s

momentum rise = 0.0241 kg-m²-rad/s



efficiency:

(0.360690495 + 0.3683771) / 2 = 0.3645337975

0.4734 / 0.3645 = 1.2988x OU WRT PE to KE

KE pre-collision = 116.9822 J

KE post-collision = 116.7322 J

KE dissipated = 0.25 J

total output energy = 0.25 + 0.4734 = 0.7234 J

0.7234 / 0.3645 = 1.9846x OU WRT net of KE + heat

So, slight drop compared to the first cycle, but still pretty much 130% for PE to KE, 200% total incl heat.

3rd cycle now running..