Success..?

[MrVibrating]

Having slept on it, it's obvious last night's conclusion cannot be correct - just look at these plots:



Solenoid1 T*a = -6.265693661

Solenoid2 T*a = 4.807124861
___________________________

Solenoids Total T*a = -1.4585688 J

Solenoids Net P*t = -1.458187881 J


The two different metrics confirm each other, however the upper integral contains -6.2 J of output work, the lower one, 4.8 J of input work..

The energy differences are clearly due to the different areas under the curves, and the net area enclosed within the spikey loops is a) obviously too small to contain more than fractions of a mJ, duh, and b) on the upper plot, the spikes are facing the 'wrong way' - that is, intruding into the gain area, so reducing it... if the spikes enclosed even part of the gain, they'd have to be oriented the other way, pointing down, not up..


So in summary:

a) the spikes don't have sufficient net area to substantiate the gain

b) the spikes are actually reducing the gain area

c) zooming in and painstakingly taking the integrals of each spike would seem futile - the 'gain' is evidently due to significant differences in the bulk areas under each curve



The more fruitful question to be following up is the causes of that bulk difference, which the spikes are simply too small to account for..


Not least, due to the fact that the CF integrals for rotor-weights 1 & 2 - controlled by the gainy solenoid - are equal and opposite!

?

This seems most perplexing, no?


• rotor-weight 1 was pulled inwards, performing 3.753509397 J of work against CF force

• its opposite partner, rotor-weight 2 moved outwards, having -3.753509641 of work performed on it by CF force


So net CF work in/out to and from the gainy solenoid is zero.


The gain hasn't come from rot-KE harnessed via CF-PE..

But likewise, it couldn't have been arising exclusively within the braking periods, either, since the whole line integral - the curve contour itself - is too high from the zero line, and the braking spikes too short and narrow to account for the difference...

..in other words, the gain condition must've been active during - and as a consequence of - the motors' 'on' phases - whilst the OB torque was being cancelled by counter-torque!

Thus the part of the interaction to be focusing on seems to be the relationship between applying that counter-balancing counter-torque, whilst lifting the masses though that constant-MoI radial trajectory...


Must admit, not at me best ATM, must be short on omega-3's or summink.. anyone else see any interesting angles in the data?

[MrVibrating]

Ok, so the 'gain' is due to the difference between the work done by solenoid1, vs solenoid2:


• sol1 moved weights 1 & 2 from an OB position, into a balanced position

• sol2 moved weights 3 & 4 from a balanced position, into an OB state

• the input vs output CF work integrals were equal and opposite for weights 1 & 2, and also for weights 2 & 3; hence neither solenoid gained or lost energy to CF force, and net CF work in/out was zero, for both solenoids

So the difference in workloads cannot be attributable to CF force..

Which seems to leave just gravity / GPE loads..?

Sol1 performs a radial lift. It raises GPE. Mostly that of the upper weight. But its integral is negative - a net output of work!? Despite CF work in/out being zero?

..meanwhile sol2 also raises some GPE - mostly that of the lower weight - and has a positive integral, a net input of work.. as you'd expect..

So is the gain condition something to do with the relative phasing of the CF and GPE workloads? Ie. both are symmetrical in their own right, but overlapping gainfully somehow?

[MrVibrating]

..here's a low-quality (ie. faster-running) animation of the cycle, for anyone else trying to puzzle this out:



..it's dropping animation frames obviously, but all the data's there..

[MrVibrating]

...so is it just me or is the act of lifting weight 2 outputting a load of work to sol 1?

..even though the outbound CF integral for weight 2 is equal and opposite to the inbound CF integral for weight 1?

So how can the CF integral be subsidising the lift?

Cuz if it isn't, then what the hell is?


Intriguing predicament, innit?

[Fletcher]

Dunno ? ... maybe it is just an artifact of the programing, or its real and you're onto something big. Keep digging and you'll eventually find out which.

It is a mystery how how in reality to split the acceleration while having a speed differential.

Any locking attempt (string, spring, damper, magnet) would engage an early momentum-clash, and would thus drain energy instead of increasing it.

Summary:

The simulator keeps the motor in a tight-enough lock with the pendulum and somehow splits the gravitational force that acts on the pendulum alone.

As a result only the pendulum should accelerate, yet the motor keeps it tight: it should invest energy in order to apply a force to keep the pendulum close from otherwise getting ahead;

Yet the implied acceleration is not registered as an effort of the motor, but it is still doing it.

Maybe it is programming that's applied to this torque that overrides the values and messes things up.

https://www.besslerwheel.com/forum/view ... 816#169816

[MrVibrating]

I figured out a small improvement on my way home this evening, regarding a problem i've mentioned previously..

The issue is this:

• in any GPE system hard-synced to system angle (as here), forcibly accelerating the system by any means likewise forces the rate of GPE interactions to increase linearly with RPM


So even if we're successfully adding 'OU KE' from the spin'n'brake cycles, it's immediately causing input GPE to rise to match whatever the current rotKE..


You can see the effects of this in those spikes on the actuator and solenoid plots - each time the brakes bite, the OB axis is accelerated by the axial momentum being dumped by the rotor-weights, causing the actuators and solenoids to suddenly accelerate to keep up..


But what if we had some means to buffer those spikes..?


As said already, hopefully the current rig/s will inform us how to go about designing a system that won't require asynchronous GPE to s&b cycles, but in the meantime we can break that hard-sync by adding a simple spring...

It works like this:

• an additional rotor is added, coaxially, on top of the existing rig; this is just a plain, balanced disc

• it's connected to the rig via a rotary spring, with a medium-ish spring constant of 10 N-m/rad

• the linear actuators, previously synced to the angle of the wheel they're attached to, are now synced to the angle of this second, sprung rotor, instead...


• so when the brakes bite, the entire system apart from the sprung 'timing' rotor recieves a jolt of acceleration, as before..

• ..but because the timing rotor lags behind slightly, so does the
actuators response time..


• ..hence the spring effectively buffers the jolts, resulting in spike-free actuator and solenoid integrals..

• ..whilst also allowing a window of opportunity for the main axis to be accelerated - and so gaining / expressing the rotKE it's being given from the braking rotor-weights - without forcing an instantaneous acceleration of the actuators lifting the weights.. ie. hopefully a window of decoupling between rotKE and input GPE..!


Gonna give it a test-drive now, adding a new elastic PE meter for the spring using Hooke's law... with any luck will shortly be able to post some much cleaner-looking integrals.. hopefully the gain'll still be there too!

[MrVibrating]

Dunno ? ... maybe it is just an artifact of the programing, or its real and you're onto something big. Keep digging and you'll eventually find out which.

It is a mystery how how in reality to split the acceleration while having a speed differential.

Any locking attempt (string, spring, damper, magnet) would engage an early momentum-clash, and would thus drain energy instead of increasing it.

Summary:

The simulator keeps the motor in a tight-enough lock with the pendulum and somehow splits the gravitational force that acts on the pendulum alone.

As a result only the pendulum should accelerate, yet the motor keeps it tight: it should invest energy in order to apply a force to keep the pendulum close from otherwise getting ahead;

Yet the implied acceleration is not registered as an effort of the motor, but it is still doing it.

Maybe it is programming that's applied to this torque that overrides the values and messes things up.

https://www.besslerwheel.com/forum/view ... 816#169816

Last time, IIRC, the exact-same code driving a motor was cut'n'pasted into a meter - so it's the same friggin' code, driving a motor here and a meter there... and this code's supplying torque data to the motor, which is duly responding... but not to the meter, which is registering zeros for every frame the torque's being applied!

Just look at that - how the flip does that happen? And to make it worse, the results seemed to confirm the hypothesis - so, not just random energy gain, but perfectly as predicted! This is why 'false positives' are so much trickier than unexpected anomalies..

But that's a condition that, just logically, shouldn't be able to arise - either the equation outputs a zero, or non-zero result, yet it's telling the motor one thing and the meter something else!


I don't think the conditions here quite match those on that occasion, however we're only two weeks into trying to crack it so far - could take another month, who knows.. plenty of time to discover new and toe-curling error modes..


All i know is, i looked at the 'chicken run' and thought "why not try it for real using OB torque?" - edged on by the question of whether the rotKE could be decoupled from the sacrificed GPE by tuning MoI; ie. a smaller-MoI would need spinning up to higher energies in order to cancel the same amount of OB torque as a larger MoI, and if you can spin up 2 J of rotKE while only forgoing 1 J of GPE, maybe you can render the effective N3 break for less energy than can be made from it.. type stuff..

..like i say, first attempts seemed to result in a non-dissipative loss, which did turn out to be error (rot dampers = dodgy integrals), but which when corrected (using motors as brakes), inverted to gain..

The chicken run was only intended to demonstrate how KE gains develop from an effective N3 violation - it surreptitiously cancels the counter-torques from the motors, forcing an N3 break, but everything else thereafter is fully legit - the resulting efficiencies are not faked; if you can sink counter-momenta to gravity for less cost than the GPE sacrificed, that's a genuine win..

Dunno.. just trying to keep the old manic tendencies under restraint and plod through it.. i reckon the above-mentioned issue of the GPE cycle being hard-synced to angle has thus far been a spanner in the works - ie. maybe we've been seeing a failure mode wherein the intended energy gain is happening, but in a manner that's forcing a conflict with other practical constraints (such as locking the actuator length precisely to system angle), in turn resulting in the sim expressing the legit gains, but in a non-physical way, or summink..

..the spring-buffer trick will hopefully remediate that somewhat, but we won't know til the figures are up.. i seem to have been wrong on just about every working-hypothesis thus far so no point sticking me neck out anymore - the s&b efficiency has the potential to be OU, the rig's designed, from the ground up, to cause and accommodate OU..

The answer's probably already there in the figures i posted last night - just a matter of figuring out how they fit together to produce the result..

The interplay between the CF work integrals and GPE lifts needs more attention - i should be able to calculate, for instance, how much GPE the actuator must've output as a function of the GMH of the outbound weight, then deduct the CF work integral from it, whilst adding the CF work integral to the GPE work done by the inbound actuator - or else, the solenoid integrals.. or both.. but one way or another the actuator and/or solenoid workloads need to be solved in relation to the CF workload; we know from first principles how much CF work there was.. so its effects and distributions between the acts and sols needs quantifying..

It's a slog but at least we got our work cut out..

[MrVibrating]

Here's the results of spring-buffering the timing wheel:


Spikes begone... and gain be quadrupled!

acts = 34.16913504

sols = -3.411870991

Motors = 1.374536542

Brakes = -0.944208082

Total In = 31.187592509 J

__


EPE = 0.087185

KE rise = 37.272837

Total Out = 37.360022 J


Diff = +6.172429491 J

__


Efficiency in relation to motor workload:

• 6.172429491 / 1.374536542 = 4.49x unity

Efficiency in relation to motor work not dissipated:

• 1.374536542 - 0.944208082 = 0.43032846 J

• 6.172429491 / 0.43032846 = 14.34x unity


Slam dunk mate. Perfect line integrals, and doubled the gain, twice over.

Coming round the M25, workforce in the road, down to one lane, red X's everywhere and 50 mph, so this bloody artic starts undertaking me in the closed lane with no way of cutting into the queue ahead, and i'm looking up at him thinking "look at this cu - hey, why not buffer the timing wheel with a spring?" - tried it the minute i got in and it bloody works! Got one right for once..


Again tho, this is just a remedial measure - in an ideal mech, the reactionless acceleration would be coupled directly to the GPE interaction, so always in-sync.

So the priority now is working out how to optimise for the best possible gain, for a 1:1 s&b to GPE cycle ratio. Then we can build Bessler wheels.

To do that, however, means first tallying up all these integrals so that they make some kind of coherent big picture... showing how the gain is directly proportionate to the effective N3 break and its efficiency..

To get a better handle on this, it'd probably be better to go for a longer spin-up cycle, of say 1 rad/s - and maybe lengthen or even equalise the braking period / braking torque so that spin-up and brake phases are equal and opposite.. this should make it easier to track the relevant quantities through their various transitions and exchanges..

Enough for tonight tho, made progress today...


sim attached

[MrVibrating]

..how you s'posed to sleep when you're staring into a white hole?


Doubled it again..

Acts = 38.02184226

Motors = 1.172330657

Brakes = -0.982954731

Sols = -15.98992563

Total PE = 22.221292556 J



KE Rise = 38.571510

EPE = 0.000019

Total Output = 38.571529 J


Net Efficiency (incl. GPE interaction):

38.571529 / 22.221292556 = 1.73x unity


Efficiency of Net Motor Work:

15.98992563 / 1.172330657 = 13.63x unity


Efficiency of Non-Dissipated Motor Work:

1.172330657 - 0.982954731 = 0.189375926 J

15.98992563 / 0.189375926 = 84.43x unity




Makes you think, with modern engineering, where's the ceiling on this thing?

Ain't there yet, that's for sure..

[MrVibrating]

...dunno if this is real or what, but reckon if we make the weight radii even narrower - like little lead cylinders, type deal - we could get the solenoid integral to exceed even the GPE / actuators input energy..

..looks to be ~38 J of GPE there - will have to meter it up at some point - but with one more doubling we'll be at +32 J already..

The crazy part is that, at last check (will keep rechecking in time), the gain isn't transferring via CF-PE... it's somehow flying under the current radar... yet it must be possible to empirically track its evolution, real or error... So is it already there in the data, perhaps in the phasing of CF and GPE workloads.. or are there further meters required (quite possibly, i expect)?

Could we maybe think about isolating the exact part of the interaction that's causing this negative tail on the solenoid plots, and do away with much of the less-lucrative parts of the action?


Ain't 16 J from thin air, either way..

[Johndoe2]

Amazing work Mr V.
Looks like you have a viable Sim. Are you ready for a real world test?

[Fletcher]

You need sleep Mr V, because when you wake up we all do our best and clearest thinking ;7)

[MrVibrating]

Cheers guys, but you know the score - for all we know i was up all night 'optimising' a rounding error..

Of course, the intended gain is a kind of 'rounding error', too - the immediate priority should be to conduct tests aimed at tracking the evolution of the gain so that it can be correlated exclusively to the "maths of OU", and not anything else.. rather than trying to run before we can walk.

Tuning for ever-higher efficiencies is fun, but the hypothesis is straightforward; short, reactionless s&b cycles using small MoI's can consolidate more energy over a given unit time than the value of the GPE sacrificed in sinking their counter-torques... so if this is correct then taking hours at a time to actually sim each specific case is not smart - better to comprehensively verify the causative principles, and then we'll know without too much doubt how any hypothetical config would perform..


@JD - looks buildable pretty much as-is, to me, tho again, it's a test-bed designed to try to manifest and measure OU in the first place, rather than actually put a gain to good use..

A purely-mechanical application based upon it may look unrecognisably different..

But as always, it's nuts even considering the consequences of success, before it's been categorically confirmed. It's maddening, this whole "is it or isn't it?" suspense... as it must've been for old Orffreus.. Gotta keep it methodical..




Dunno if i'll get much done tonight, pretty wrecked, but the test to knuckle down on is a single s&b cycle spread over a single GPE cycle; solve that to within a mJ, then go for a 2:1 mix, then 3:1 etc. etc. to see if we're really rounding up an objective momentum gain underwriting the KE rise, and not some weird error..

One thing i may try after dinner tho is retaking the +16 J result above - think i might've mixed figures from two similar runs since the KE i quoted doesn't quite match the screenshot.. but it was late... also, wanna take the CF integral from that run to see if it might correlate with the gain in some way..

[MrVibrating]

The v1_1 iteration was a bit rushed, so rather than taking all the data again tonight, i did some tidying - just eliminating potential weaknesses: no more nearo-zero masses, added a switch to detect when TRS=0 and override the motor code to ensure "0" means zero.. rescaled the meters & other small tweaks.

Will try remeasuring the +16 J result with it tomorrow, & post with an anim if time.

Here's a photo finish for now:




Sim's attached - those with WM might be interested to note the following details:

• note that the 0.1 rad/s acceleration of 1 kg-m² costs just 0.005 J each cycle, per ½Iw²

• note that at the start of the run, the OB axis is gaining KE at the rate of 0.0005 J per step, from the subsequent braking of those 0.005 J spin-ups

That is, only 10% of input energy is going to rotKE of the main axis..

• note that towards the end of the run, it is now gaining at the rate of 0.25 J per step

That's 500% of input energy, going to orbital rotKE about the central axis, per cycle..

• note the divergence between the axial and orbital momenta; the KE value of the former is being transposed by the ever-rising velocity of the latter; however the PE cost of the axial workload remains in the accelerating FoR, relative to which it is performing a constant workload, while KE is relative to the static frame..

So bashically the current velocity of the OB axis is adding to the velocity metric the KE's using, but not the one the PE's using.

That's the broad picture anyway. The real breakthrough is that the energy efficiency of using gravity to accomplish this is an arbitrary function of axial to orbital MoI and cycle ratios.


All of this is to be thoroughly demonstrated, of course.. but if you have access to WM - or just the posted data - you don't need to be taking integrals to be checking key details..

..such as this fact that the efficiency of the motor workload is evolving, linearly, with respect to RPM, in relation to the balance of GPE..

If we can correlate the KE gain to that rising orbital velocity, per ½Iw².. then dammit if this ain't OU - brute-forced, from first principles - signed, sealed & delivered..?

[MrVibrating]

Surprise...


..just measured up that more polished sim:

Acts = 38.257711

Sols = -0.155918299

Motors = 1.136253226

Brakes = -1.001597421

Total PE = 38.236448506



KE Rise = 38.419899

EPE = 0.000009

Total Out = 38.419908

Diff = +0.183459494 J



This was the same config that made +16 J previously..


So what's caused this change?


The actuators move the solenoids radially, and the solenoids vary the gap between the weights to lock the MoI; 'constraints' in WM are notionally massless - you have to add a body to a constraint to give it some mass... in this case, the solenoids are attached to a 'slider' - a small mass on a keyed slot joint - which is the actual body being moved by the actuator..

I'd initially set the mass of these sliders very low, in order to 'purify' the system of extraneous weight or MoI besides those of interest to the interaction / measurement..

In principle this usually causes no problems - the masses and MoI's of these very-light bodies are still included in the metering equations (so for example last night when i increased these masses, i didn't need to make any corresponding changes to the metering), and the sim's set to use 16 digits internally, so even if i'm only displaying six zeros, these light masses / MoI's are still being calculated to ten more decimal places under the hood..

..in principle..




In the above result, the slider masses have only been increased to 0.001250 kg.

1.25 grams. Hardly realistic, yet the gain's all but gone already...


So it almost certainly was error all along..!



F*ck me, maybe now i can get a good night's sleep..



Might yet give it a few more spins with different tweaks - but only after further raising all masses to 'realistic' practical values..


Could the error mode nonetheless point to a potential exploit? How exactly was the error proceeding?

I suspect that the low mass of the sliders was causing an effective N3 break - i'd assumed that since it's connected to the wheel via a keyed slot joint, all forces applied to it would be immediately commuted to the wheel.. however, perhaps due to having insufficient mass, WM calculated infinities, or some kind of buffer overrun, clipping data in the 3-way exchange between wheel, sliders and solenoids, and the weights they're moving.. if this was happening differently between spin-up and braking phases, then you're successively accumulating a rounding error..


However the points that had me so optimistic last night still stand - look at the efficiency of the motor workload between start and end of the quarter-turn run; it really is massively OU:

• the per-cycle motor input energy really is 0.005 J

• the per-cycle KE rise of the OB axis really does start out at 0.0005 J..

• ..and really does rise to over 0.25 by the end of that single GPE drop

• 0.005 really does divide into 0.25 fifty times! Honest!

• moreover, the brake really is dissipating around 90% of that input energy..

• ..so the efficiency of the non-dissipated input energy is actually not 500%, but closer to 5,000%


Unfortunately though, as usual, the system is giving us this tantalising view of these stupendous efficiencies, yet the input energy cost of actually rendering those gain conditions - here, the input GPE - is equal to the 'OU' efficiency of the unilaterally-accelerated workload..


So i haven't decoupled per-cycle momentum yields from RPM, yet; that is, the amount of momentum you can make by sinking counter-momenta to gravity is equal to whatever you would've got from the sacrificed GPE, had it been allowed to gravitate passively..

Like i say tho i'll make one last sweep through the variables; larger / smaller MoI's / spin-up speeds / brake powers etc. etc., but using much more mass for the previously-'aerogel' components.. yeah, don't hold yer breath..

Sorry everyone for the drama, and for being such a useless tw*t at this..