Mechanising the maths

[thx4]

Just one question: are you vertical (with gravity incidence) or horizontal (without gravity)?

[MrVibrating]

It's continually-overbalancing so yes, with vertical gravity. The GPE meter is logging the rising center of gravity, and that last run was stopped at the instant that rising center of gravity reached 90° horizontal, at peak overbalancing torque (with no speed-dependent factor it'll just keep accelerating forever otherwise).

[MrVibrating]

Some further notes:

• setting the OB weights heavy enough that the OB moment remains hanging below, never climbing, results in considerable loss

Similarly, if the system syncs such that the OB moment spends more time on the ascending rather than descending side, the input energy is lost.

Note that this loss is non-dissipative - the energy's been spent raising weights at a loss, apparently sunk to gravity. This would be consistent with the I/O energies being thermodynamically decoupled; ie. with the system being inherently non-conservative..

• when the OB moment is consistently on the descending side, we get this persistent 0.58% gain..

[MrVibrating]

Had two further ideas while at work:

• add MoI counter-balancers to the main wheel

Currently, the two linear kiiking weights are causing significant MoI variation and thus stray inertial torques, accelerating and decelerating the main wheel, and thus also modulating the CF force. However we could add a further pair of radially-sliding masses whose motions perfectly cancel out this extraneous MoI variation; their work-done would presumably be a zero-sum, and this will smooth out the operation as well as eliminating any vagaries of how these inertial torques may or may not be interfering with the measured disunity.

In the past i'd have approached a problem like this using a kind of servo mechanism that automatically balances the MoI, adjusting mass radii dynamically on the fly using reactive feedback, however while this works it can muller data quality; hence this would be a good opportunity to crack this mathematically using a simple minimum function, something less volatile and potentially spiky... I have a rough idea how to tackle it, but might have to wait till the w/e for some quiet time to think it through..

The other idea is probably overlooking something crucial that'll render it useless, but just on the face of it:

• what if the vMoI spun up in the opposite direction to the wheel?

Having it spin in the same direction was a deliberate choice to try and harness the benefits of any reactionless accelerations that might be so effected; however consider the situation if the main wheel is overbalancing at say 10 rad/s in one direction, while the vMoI has an absolute speed of only 1 rad/s in the opposite direction; if it's possible to purchase angular momentum from G*t in a velocity frame rotating at 10 rad/s, by only performing input work in a velocity frame that's going ten times slower, then we'd only have to pay a fraction of the KE value of that momentum! Perhaps as much as 10 or 20x OU in one fell swoop!

About the only critical requirement i can currently foresee is that the vMoI can't approach absolute zero, since it depends upon having some intrinsic CF force in order to cause acceleration and thus a useful power stroke. Just in principle however, at 1 rad/s we could purchase 1 kg-m²-rad/s for just half a Joule of input work against CF force. The key detail that makes such a proposition seemingly tenable is simply that the CF kiiking mechanism can run asynchronously to the OB mechanism. But perhaps i'm wrong, will have to see how it pans out..



Final thought for now: the fact that the system can produce non-dissipative losses (there's no friction, collisions or any dissipative loss mechanisms present in the sim) demonstrates that it is a thermodynamically-open system. Non-dissipative losses are the corollary of energy gains; ie. an under-unity result of exactly the same kind of disunity as a gain; only the direction of the asymmetry is changed. Doesn't necessarily mean the gain's real or that it can easily be optimised to useful levels if true, but does auger well insofar as the fact that it's not simply elastically storing energy; it sinks it, to gravity and time.. and in a way that's intuitive and easy to understand, no magic involved. Is it really also sourcing it though?

Watch this space..

[MrVibrating]

I just tried the inverted sync option:



CF-PE = 23375.91224 J

Net energy rise = 23311.425785299 J

..basically -64.49 J down, ie. under-unity, again by a fraction of a percent (about half the previous anomaly).

Doesn't appear to help, then.

But more usefully, it tells us that the gain condition is dependent on co-rotation, so, consistent with an effective reactionless acceleration.

There must be some basic permutation that'll begin to push that 0.58% gain factor into more useable territory... need to isolate exactly when and where it's arising then begin optimising it..

Wanna implement the MoI-balancing first tho, smooth out the action..

[agor95]

Hello MrVibrating

I do not know if this is possible in your software.

Can you setup a test rig where the device is in motion.

The start and test run are for a section of the graph shown.

However the Delta Time is reduced. Working on the principle the software is doing numerical integration.

The process of comparing different Delta segment sizes for the same section will build confidence
in the results.

Regards

[MrVibrating]

The CF-PE meter (the measure of input work-done) is integrating CF force (calculated as mass times radius times angular velocity squared) over radial displacement, ie. over displacement of the linear actuators on the central vMoI crank. So each contour line heading right-to-left represents an inbound stroke where MoI is decreasing, and the return left-to-right contour maps the outbound stroke where MoI's increasing again. This may seem to muddy the objective of 'taking the area under the curve', however what the meter's recording is a long unbroken string of force and distance values in two columns, and this is what gets exported and crunched with a Riemann sum in a spreadsheet.

The CoP is thus less sensitive to run times, than whether the OB moment is climbing up one side or the other; i get what you're saying tho and agree; isolating the gain condition will probably involve trying to zoom in on a single-cycle example - examining a single full cycle of the gain interaction as a microcosm of the general CoP results..

Reasons to remain circumspect: this software never ceases to amaze in the kinds of errors it shouldn't but sometimes does introduce; sometimes, data elements that seem and should be trustworthy are erroneous. In this particular instance, both P*t and F*d integrals - calculated by the sim - are showing gain, but also the CF-PE integral, the point of which is independent calculation of the CF force from simple empirical theory. M*r*w² / d can't be wrong, yet it still depends upon the sim to output accurate values of position in time, and velocity.. hence if the CF-PE values are false, this would seem to be the only possible explanation. I'm taking data at glacial precision settings across the board however, ie. 1e-11 limit on integration, assembly and overlap error (although there's no collisions enabled anyway), 16 digits internal and 9 digits of output data per value.. and as i noted, this only seems to refine the gain factor, rather than reducing or changing it..

Reasons to remain engaged with it: the nature of the non-dissipative loss when the OB moment's on the ascending side does not seem anomalous, making perfect sense, yet at the same time appears to satisfy the classical definition of 'destroying energy'; whereas we'd intuitively expect a mechanically-closed system to conserve energy, this one's thermodynamically open. Yet this is not controversial, since the system's also open to gravity and time, and thus, momentum exchange with its environment, and per the vis viva resolution, CoE is dependent upon CoM. So, if it can reasonably destroy energy..

Then of course there's the hypothesis behind its inception, which may or may not be validated by this result, but which again is simply an inexorable extrapolation from presumption of vis viva certainties; mechanical OU is only reconcilable in terms of a divergent inertial frame on whatever the input-energy workload, ie. a PE discount rather than a 'KE excess' (which is an oxymoronic concept). Last night's discovery that inverse rotation of the kiiking action eliminates the gain is also consistent with the reactionless momentum solution implicit to an unconflicted resolution of mechanical OU - again, fling a dart while coasting on skates, sans recoil, and its resulting KE in the stationary frame with be more than your PE expended in the moving frame. Inertial torques from the ice-skater effect - and more generally, momentum gains direct from G*t rather than by pushing against some other inertia or stator - are interesting precisely because they seem to sidestep the usual necessities of generating equal opposing counter-momenta. This is the conjecture, which may or may not be right, or validated by current results, which may or may not be a false positive (and a narrow one at that).

If the conjecture's right however then it should be possible to further optimise the margins, so we still have our work cut out for now..

Currently working eves, so working around the usual free time constraints here; i do want to implement the MoI-balancing idea to eliminate stray inertial torques and smooth the operation - as well as eliminating this presumably-extraneous MoI variation on the main wheel from whatever the gain conditions - but i'll also be mulling over the 'minimum system' interaction for zooming in on whatever's happening on a per-cycle basis..

[agor95]

Hi MrVibrating

Thank you for your description of the thought process and system validation.

With any virtual system knowing the limits of the software is as important as the results.

It's a tricky place to be holding to the conservation symmetries and looking for momentum gains.

Good Luck

[MrVibrating]

Minor update:

Ain't slept much last night, but have made some ground:

• found & fixed a source of mechanical instability that made the thing too explodey to run at fixed integration steps, important for maximum precision

To drive the OB crank in the same direction as the rotation requires an additional internal rotor to invert the angular directions, so to provide a stable platform to attach this to i added a second internal rotor using the same method as the OB crank, via two orthogonal slot joints; its subsequent co-rotation is superfluous, since it merely provides a base for which to attach the inverter gear, another wheel pinned on top of it coaxially, on its own free axis. However there'd then be nothing to prevent it rolling around inside the perimeter, inevitably dropping down to join the OB crank, so to support it in place i added a rigid rod running between the axes of these upper and lower internal wheels.. and this was the source of the problem, admitting a small lateral motion that subsequently stressed the connecting rods. The solution was to replace that rod with a thin rectangular brace, thus providing the opportunity to add a third pin joint in its center, affixing it coaxially to the wheel axis. The sim can now be run at arbitrarily-high precision settings in single integration steps, making for much more consistent, and trustworthy, data (this is how i usually resolve systems to unity with a millijoule noise floor).

Just as a throwaway example, in the attached refined model of a previously-posted run, the system has been primed up to its 2 rad/s starting speed, then all of the startup gubbins disabled, allowing a full 32,765 frames just doing its thing on a free axis; measuring at 1e-5 integrator error limits vs 1e-16 shows zero difference, the efficiency of this initial, non-optimised and quite arbitrary config is, with a high degree of confidence, 1.0957 % in current form. There's good reason to believe it can be pushed much higher.. (but just as an aside, recall that the 'quarters' riddle alludes to 16x gain factors..)

I'm also a bit clearer on what to measure and what not to bother with - wasted more time than i'd care to admit last night comparing efficiencies of various prospective refinements including vMoI speed relative to wheel speed as a function of I/O gear ratios, but without bothering to stabilise the OB moment, so even when it was consistently on the ascending side, it'd still start out oscillating between the rising and falling sides.. and of course, all of the time it's on the rising side, we're burning energy to perform work in causing gravity to decelerate the system, scrubbing momentum to G*t.. derp.. - what's the point of comparing two runs with different gear ratios if one spends more time on the wrong side than the other? All we want to know is the efficiency of buying momentum from G*t, not shedding it back there. Basically it's only worth measuring runs in which the system's consistently gaining momentum, since the CoP of that momentum gain is all that matters for now.

So we now have a stable basis for experimentation and analysis, at least. The data integrity appears rock-solid. I'll put this to the test however by running P*t and F*d integrals alongside the CF-PE metric - these should now show better agreement between practice and theory. Three different metrics on the input energy = "compelling" eh..

As regards the minimum-config to zoom-in on, i'd suggest the final vMoI cycle from a run such as the one above, as the system's climbing up to its peak OB moment; that last full 360° cycle of the kiiking action can be spread across 32,765 frames, so we'll be able to highlight exactly where in the cycle the gain (cough PE discount) is arising.

But all this is still jumping somewhat ahead; i really need to add the MoI-balancers to eliminate this unwanted ice-skater effect on the main wheel. Things are looking up though, and i'm excited by the possibilities going forwards, so many variables to try tweaking..

[MrVibrating]

Since this is basically a reference example of a seemingly-successful config, here's the anim and data table to give those w/o the sim something to ooh and ah over:



Dimensions = 5 m radius
Mass = 66.1 kg
Runtime = 21.3 secs
Initial net energy = 1499.800016411 J
Final net energy = 31179.310102327 J
Net energy rise = 29679.510085916 J
CF-PE = 27086.7502 J
Gain = 2592.759885916 J
Net O/I CoP = 1.0957 %

There, that's what a nigh-on 10% gain looks like - 2,500 J over 21 secs averaging to 119 Watts, obviously no show-stopper in terms of power density just yet but early days eh..

The exploit seems pretty much confirmed, i think, but let's see how well the P*t and F*d metrics agree..

[MrVibrating]

Bwah, just when you thought it was safe to go back in the water:


Same run so static image, no anim necessary

Initial Energy = 1499.800016411

Final Energy = 31179.119604656

Net Rise = 29679.319588245

CF-PE = 27086.7502

P*t = 30042.60628

F*d = 30044.7002

CF-PE says we should be 2592.6 J up, but the forces actually acting on the actuators are summing to a -365.4 J loss.

So by 2:1 vote, the CF-PE calc is relegated to obsolescence.. so much for my iron-clad baseline (it's a fair cop)..

But the system's still considerably non-conservative, just under, rather than over, unity, so we're still looking at an interesting situation..

Now that we have two seemingly-reliable input-energy meters we still have a solid basis for further experimentation; we're currently gaining angular momentum, but at negative efficiencies, in a system without any dissipation mechanisms available to it.

As such, it's still an anomaly, and of the right kind, if not the desired sign. If the efficiency changes in consistent directions with consistent incremental tweaks, we're going to see CoP varying across a range of values, with any luck not all necessarily negative like this..

The ratio of vMoI to GPE cycles seems one obvious area to explore, via gearing ratio tweaks: remember, the intended exploit is that the net cost of many small bites of reactionless momentum can sum to less than their combined KE value, hence both the number of cycles of one to the other is of interest, as well as the relative speeds which in turn determine CF force magnitudes.

It should now at least be possible to explore the results of these kinds of speculations by cross-referencing between these two consistent metrics anyhoos..

[MrVibrating]

..desperate to end this mammoth-sesh on some kind of payoff, i've just tried upping the gear ratio, en-speedening the vMoI relative to the wheel.

The more fasterised i tweaked it, the closer the loss got to unity - the right direction - so i gave the knob one last twist and can now solemnly report, before i must scurry off to earn me daily bread, that these freshly-calibrated metrics are both now measuring gain above noise. The run was messy with OB dwell time on the wrong side, so that's highly preliminary and i expect things to only keep on improving with time; the premise that more bites of cooler pie add up to a larger slice of hotter pie, type stuff, appears to be validated by this power ratio optimisation.

Note that the scissorjacks are consistently represented as a form of power transmission in MT, esp. in harnessing output rotational KE back into input GPE..

What we appear to be looking at is basically transmission of force / torque passing through different velocity frames that are, in some meaningful sense, inertially isolated from one another; many small bites of pie in one velocity frame are effectively wrangling discount momentum in the other.. or more fundamentally, the input and output energy values of momentum appear to be thermodynamically - and quite arbitrarily - decoupled.. gain or loss a matter of the relative velocity frame difference. Or to put it another way, the inertial reference frame of the input-energy workload is divergent from the absolute frame!

Things are getting interesting eh..

[MrVibrating]

Final thought for now:

• It's no longer a physics problem; it's an engineering one.

[thx4]

• It's no longer a physics problem; it's an engineering one.

And then there's believing or knowing?
Physics is inescapable, engineering requires understanding where the energy could come from.
When it's finally clear, everything becomes simpler 🙂

[MrVibrating]

From / to G*t, apparently. At least, that's the momentum source / sink; the energy source sink may more reasonably be attributed to whatever it is that constitutes 'inertia', but meh, academics for now eh..

Did have one more thought however - in principle it may be possible to drive the loop the other way around, with a motor supplying torque between the vMoI and wheel, programmed to accelerate or decelerate however's required in order to keep the OB moment at its optimal 90° horizontal angle; this should supercharge the cycle, with the vMoI actuators now harvesting the resulting gains.. If that works, the thing would be free to accelerate to silly power densities.. may give it a shot later at some point..