Decoupling Per-Cycle Momemtum Yields From RPM
Moderator: scott
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
@ Silent - Cheers mate, just getting my freak on - FA else to do eh.. 'least i'm not out there getting the virus. Or on Pornhub, getting a virus. My WM crack does keep trying to give me a virus but MSE seems to be producing the right antibodies, and i expect i rooted myself when cracking my OS anyway, so it's all good..
Just identified another previously-mysterious jigsaw piece - the seemingly-arcane symbolism of the four-paned windows in the Merseburg prints:
• in the two 'box of bricks' versions, the rope exits thru the top left window pane
• the suspended load is in tension with the stampers, as if they're opposite ends of an interaction (ie. I/O)
• yet in the water-screw print, the water draining thru the same window pane below is obviously not in tension with anything in the system
So, something to do with 'quadrants' of a rotation, or interaction, indicating something about the 'first quadrant'? It's a bit woolly and imprecise innit?
If the former images are meant to portray an I/O interaction - ie. the box of bricks appears to be involved in some kind of interaction with the stampers, moderated by pendulums, cranks and a flywheel - then the latter, water-screw image would break continuity, since the draining water can't transmit tensile forces.
The apparent resolution that's just jumped out at me is the frickin' 25% per-cycle efficiency multiplier indicated by the Toys page..
Not unusually, i've spent the past few days with the following images laid out across my screens: MT 133 & 134, the Toys page, the three Merseburg prints as well as this related one.
What i'm currently looking for in them is some kind of common thread that might speak to the possibilities for divvying up momentum-from-gravity asymmetrically, somehow, and accumulating the resulting per-cycle increase.
Recall that i'm working opposite ends of the problem, until they meet in the middle at something i can actually test; so i start out from certain axioms:
• 'KE' is defined by half the inertia times the V-squared relative to the ground FoR
• B's wheel's weren't changing mass or size during their runs - ie. their net inertia was constant
• thus "excess KE" is an oxymoronic notion; by definition, a given inertia always has precisely the right amount of KE for its given velocity, and no more can be assigned or even envisioned notionally
• therefore mechanical OU is only possible if we can somehow pay less to accelerate inertia than its resulting KE value
• such PE discounts are only possible if EMGAT - ie. no stators, otherwise the input energy cost of acceleration squares with velocity in relation to that torque axis
• hence the momentum source has to be somehow reactionless - we need to somehow Bruce Lee it, and 'torque without torquing'
• as elaborated yesterday, the only possible statorless momentum source here is an I/O G*t asymmetry
Basic deduction, nuking whales in a teacup, just feeling our way down the corridor.. which leads us to consider how these prospective PE discounts would necessarily stack up, in relation to their KE value:
• the minimum input energy cost of momentum set by the KE equations (ie. by the universe) for a 1 m/s or 1 rad/s acceleration of a 1 kg linear or 1 kg-m² angular inertia is ½ J
So let's keep buying at that rate, noting PE-KE symmetry - i'll stick to angular, just to keep it simple, but it's mathematically irrelevant: 1 kg-m² @ 1 rad/s = ½ J, so unity for the first cycle, but then at the second we pay another ½ J to reach 2 rad/s, so now we have 1 J total input, but 2 J of KE, hence 200% OU. Simple or what? This is a per-cycle efficiency accumulator of 100% - it literally gets 100% more efficient every cycle, in principle, up to infinite RPM..
However when we consider the kinds of mechanical workloads we'd need to accomplish in order to cause these desired 1 rad/s accelerations each cycle, N3 immediately blocks our progress, and we find that OU in 2 cycles is not going to be possible - because there's inevitably an energy / work cost involved in rendering the effective N3-violating conditions needed to generate and collect the reactionless momenta.
So, still in purely-hypothetical mode, let's lower our efficiency expectations and reconsider: suppose we can fix a 1 J / kg-rad/s tariff across some RPM range: at cycle #1 we've spent 1 J, for a 1 rad/s acceleration of 1 kg-m², so we have ½ J of KE and 50% of our input energy has been dissipated; at cycle #2 we've spent 2 J, for now 2 rad/s on 1 kg-m², so we're at 2 J KE and unity.. and a third cycle obviously takes us to 3 J in for a final speed of 3 rad/s and thus an output KE of 4.5 J - unity in two cycles, and 150% in three. This is a per-cycle efficiency accumulator of 50%.
If we crank it down another notch and consider a 1.5 J / 1 kg-m²/rad/s tariff, we get: cyc#1 sees 1.5 J in for ½ J out, @#2 = 3 J in for 2 J out, @#3 it's 4.5 in for 4.5 out (unity), #4 = 6 in for 8 out ; 133%, with a 33% per-cycle efficiency accumulator.
One more notch down the ladder of realistic-expectations; suppose it's 2 J per rad/s per kg-m²: cyc#1 = 2 J in for ½ J out, #2 = 4 in for 2 out, #3 = 6 in for 4.5 out, #4 = 8 in for 8 out (unity) and #5 = 10 J in for 12.5 J out, 125% with a 25% per-cycle efficiency accumulator.
So that last route assumes fully 75% of all input energy gets wasted each cycle.. but we benefit from the resulting 25% p-c accumulator after five cycles...
Now go back to items 'A' and 'B' on the Toys page - the vertical chain links represent pairs of torques or momenta coming from left-to-right sides of the axle, but only single ones going back right-to-left; thus an asymmetric torque / momentum cycle, and repeated specifically 5 times down the length.. apparently culminating in "something extraordinary"..
What the Toys page is obviously depicting is an asymmetric accumulation of momenta with a 25% p-c efficiency accumulator...
..and so the 'output quadrant' of the window panes in the Merseburg prints correlates with that 25% p-c efficiency accumulator indicated in the Toys page - whatever the fundamental interaction these images are intended to encode or guardedly reveal must, by elementary deduction, be a G*t momentum yield depending on a mechanism with an intrinsic 25% p-c accumulator, hence dissipating fully 75% of its p-c input energy.
If these losses are entirely conventional, then they're 'thermodynamic' - ie. dissipated as heat losses - and since friction isn't an elementary necessity (it can be reduced with bearings), the only fundamental sink for such necessary losses is inelastic collisions - undoubtedly, then, the bangs heard emenating from B's wheels.
Once again, then, we're prompted to consider what types of inertial interactions would necessarily dissipate 75% of input energy per cycle? The answer's inelastically colliding inertias in a 3:1 ratio..
Again, note that the AP wheel is placed after an apparent jibe at Wagner, cursing him by his own infidelity to the truth, as a kind of arcane seal on the deal - the image shows three 'quarters'.. three quadrants.. 75% loss.. but what of the missing fourth quarter?
It's all Kircher-esque hieroglyphs, to be sure, yet the depicted clues do align consistently to the de-facto mathematical principles of mechanical OU, and in very specific reference to this particular '75% loss, 25% gain' efficiency envelope..
And so that's what's exiting through those figurative window panes - all of the momentum generated each cycle, only at 25% p-c energy efficiency, from an inertial interaction in a 3:1 ratio - either four identical masses interacting 3-on-1 in a rotating cycle, or else two inertias in a 3:1 ratio.
The only other slight variation that might be worth considering is if the 75% loss is not entirely dissipated in the classical sense - this could only arise in principle if we only got to keep half of the momentum we had to pay for each cycle - so for instance if we had to pay for momentum and counter-momentum, but only got to keep the former, yet still have to incur an inelastic collision between inertias in at best a 1:1 ratio thus dissipating another 50% of the 50% of input energy we had remaining.. hence 2 J / kg-m²-rad/s = +25% per-cycle.. IOW, the gain interaction could involve non-dissipated losses, in addition to the minimum 50% energy p-c dissipated by the collisions..
I'm still playing with those diametric pendulums / lever weights - using OB torque or a spooling weight to introduce momentum to a rotating system, and then somehow deploy those long internal weight levers to generate an internal momentum asymmetry.. nothing doing yet tho..
Just identified another previously-mysterious jigsaw piece - the seemingly-arcane symbolism of the four-paned windows in the Merseburg prints:
• in the two 'box of bricks' versions, the rope exits thru the top left window pane
• the suspended load is in tension with the stampers, as if they're opposite ends of an interaction (ie. I/O)
• yet in the water-screw print, the water draining thru the same window pane below is obviously not in tension with anything in the system
So, something to do with 'quadrants' of a rotation, or interaction, indicating something about the 'first quadrant'? It's a bit woolly and imprecise innit?
If the former images are meant to portray an I/O interaction - ie. the box of bricks appears to be involved in some kind of interaction with the stampers, moderated by pendulums, cranks and a flywheel - then the latter, water-screw image would break continuity, since the draining water can't transmit tensile forces.
The apparent resolution that's just jumped out at me is the frickin' 25% per-cycle efficiency multiplier indicated by the Toys page..
Not unusually, i've spent the past few days with the following images laid out across my screens: MT 133 & 134, the Toys page, the three Merseburg prints as well as this related one.
What i'm currently looking for in them is some kind of common thread that might speak to the possibilities for divvying up momentum-from-gravity asymmetrically, somehow, and accumulating the resulting per-cycle increase.
Recall that i'm working opposite ends of the problem, until they meet in the middle at something i can actually test; so i start out from certain axioms:
• 'KE' is defined by half the inertia times the V-squared relative to the ground FoR
• B's wheel's weren't changing mass or size during their runs - ie. their net inertia was constant
• thus "excess KE" is an oxymoronic notion; by definition, a given inertia always has precisely the right amount of KE for its given velocity, and no more can be assigned or even envisioned notionally
• therefore mechanical OU is only possible if we can somehow pay less to accelerate inertia than its resulting KE value
• such PE discounts are only possible if EMGAT - ie. no stators, otherwise the input energy cost of acceleration squares with velocity in relation to that torque axis
• hence the momentum source has to be somehow reactionless - we need to somehow Bruce Lee it, and 'torque without torquing'
• as elaborated yesterday, the only possible statorless momentum source here is an I/O G*t asymmetry
Basic deduction, nuking whales in a teacup, just feeling our way down the corridor.. which leads us to consider how these prospective PE discounts would necessarily stack up, in relation to their KE value:
• the minimum input energy cost of momentum set by the KE equations (ie. by the universe) for a 1 m/s or 1 rad/s acceleration of a 1 kg linear or 1 kg-m² angular inertia is ½ J
So let's keep buying at that rate, noting PE-KE symmetry - i'll stick to angular, just to keep it simple, but it's mathematically irrelevant: 1 kg-m² @ 1 rad/s = ½ J, so unity for the first cycle, but then at the second we pay another ½ J to reach 2 rad/s, so now we have 1 J total input, but 2 J of KE, hence 200% OU. Simple or what? This is a per-cycle efficiency accumulator of 100% - it literally gets 100% more efficient every cycle, in principle, up to infinite RPM..
However when we consider the kinds of mechanical workloads we'd need to accomplish in order to cause these desired 1 rad/s accelerations each cycle, N3 immediately blocks our progress, and we find that OU in 2 cycles is not going to be possible - because there's inevitably an energy / work cost involved in rendering the effective N3-violating conditions needed to generate and collect the reactionless momenta.
So, still in purely-hypothetical mode, let's lower our efficiency expectations and reconsider: suppose we can fix a 1 J / kg-rad/s tariff across some RPM range: at cycle #1 we've spent 1 J, for a 1 rad/s acceleration of 1 kg-m², so we have ½ J of KE and 50% of our input energy has been dissipated; at cycle #2 we've spent 2 J, for now 2 rad/s on 1 kg-m², so we're at 2 J KE and unity.. and a third cycle obviously takes us to 3 J in for a final speed of 3 rad/s and thus an output KE of 4.5 J - unity in two cycles, and 150% in three. This is a per-cycle efficiency accumulator of 50%.
If we crank it down another notch and consider a 1.5 J / 1 kg-m²/rad/s tariff, we get: cyc#1 sees 1.5 J in for ½ J out, @#2 = 3 J in for 2 J out, @#3 it's 4.5 in for 4.5 out (unity), #4 = 6 in for 8 out ; 133%, with a 33% per-cycle efficiency accumulator.
One more notch down the ladder of realistic-expectations; suppose it's 2 J per rad/s per kg-m²: cyc#1 = 2 J in for ½ J out, #2 = 4 in for 2 out, #3 = 6 in for 4.5 out, #4 = 8 in for 8 out (unity) and #5 = 10 J in for 12.5 J out, 125% with a 25% per-cycle efficiency accumulator.
So that last route assumes fully 75% of all input energy gets wasted each cycle.. but we benefit from the resulting 25% p-c accumulator after five cycles...
Now go back to items 'A' and 'B' on the Toys page - the vertical chain links represent pairs of torques or momenta coming from left-to-right sides of the axle, but only single ones going back right-to-left; thus an asymmetric torque / momentum cycle, and repeated specifically 5 times down the length.. apparently culminating in "something extraordinary"..
What the Toys page is obviously depicting is an asymmetric accumulation of momenta with a 25% p-c efficiency accumulator...
..and so the 'output quadrant' of the window panes in the Merseburg prints correlates with that 25% p-c efficiency accumulator indicated in the Toys page - whatever the fundamental interaction these images are intended to encode or guardedly reveal must, by elementary deduction, be a G*t momentum yield depending on a mechanism with an intrinsic 25% p-c accumulator, hence dissipating fully 75% of its p-c input energy.
If these losses are entirely conventional, then they're 'thermodynamic' - ie. dissipated as heat losses - and since friction isn't an elementary necessity (it can be reduced with bearings), the only fundamental sink for such necessary losses is inelastic collisions - undoubtedly, then, the bangs heard emenating from B's wheels.
Once again, then, we're prompted to consider what types of inertial interactions would necessarily dissipate 75% of input energy per cycle? The answer's inelastically colliding inertias in a 3:1 ratio..
Again, note that the AP wheel is placed after an apparent jibe at Wagner, cursing him by his own infidelity to the truth, as a kind of arcane seal on the deal - the image shows three 'quarters'.. three quadrants.. 75% loss.. but what of the missing fourth quarter?
It's all Kircher-esque hieroglyphs, to be sure, yet the depicted clues do align consistently to the de-facto mathematical principles of mechanical OU, and in very specific reference to this particular '75% loss, 25% gain' efficiency envelope..
And so that's what's exiting through those figurative window panes - all of the momentum generated each cycle, only at 25% p-c energy efficiency, from an inertial interaction in a 3:1 ratio - either four identical masses interacting 3-on-1 in a rotating cycle, or else two inertias in a 3:1 ratio.
The only other slight variation that might be worth considering is if the 75% loss is not entirely dissipated in the classical sense - this could only arise in principle if we only got to keep half of the momentum we had to pay for each cycle - so for instance if we had to pay for momentum and counter-momentum, but only got to keep the former, yet still have to incur an inelastic collision between inertias in at best a 1:1 ratio thus dissipating another 50% of the 50% of input energy we had remaining.. hence 2 J / kg-m²-rad/s = +25% per-cycle.. IOW, the gain interaction could involve non-dissipated losses, in addition to the minimum 50% energy p-c dissipated by the collisions..
I'm still playing with those diametric pendulums / lever weights - using OB torque or a spooling weight to introduce momentum to a rotating system, and then somehow deploy those long internal weight levers to generate an internal momentum asymmetry.. nothing doing yet tho..
re: Decoupling Per-Cycle Momemtum Yields From RPM
Great post MrV and even though I get lost in the math, I still have to say that the 75% loss 25% gain matches what circle said on overunity.com when he said that .2 to .25 of the weight set is left hanging out in thin air - the part that actually drives the wheel...one weight of the pair of pairs.
Love your work!
silent
Love your work!
silent
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Just doodling, and this is probably sim error, but seeing a small persistent anomaly:
(Other simmers, hit ctrl-A to 'select all' then double-click 'show' in the 'Appearance' widget to reveal everything - there's an MoI calc for calibrating the pendulum masses, and the GPE meter sits on top of three more hidden ones, since the net GPE equation for every mass in the sim is too long to fit into a single meter. Additionally, i wanted to be able to spool the weight off either wheel for comparison, so attached one to each and just pinned one to the background with its rope deactivated, rather than having to keep rewriting the equations - you can swap between 'em, activate both at once or neither.)
• the pendulums each have the same MoI as the blue flywheel they're cranking
As mentioned, i was investigating opportunities for causing an asymmetric internal distribution of momentum sourced from gravity (still ongoing).
• when the weight spools off the outer wheel instead, we still see a small anomaly but it never grows to significance
• this is almost certainly sim error, and even then, 1 J in 225 should harldy prick interest
• the sim's set to pause whenever the error reaches <= 1 J - it seems to be ramping up by that point tho, climbing in ever-larger discrete jumps..
..this last point should help with debugging presumably..
• the only potentially-lossy component here is the rope, being set to '0' elasticity, however i don't see why it should be dissipating anything under these conditions..
• the loss seems to increment most significantly as the pendulums change direction..
• could be a rounding error in the angular-to-linear conversion constants?
• anomaly appears unchanged by raising sim frequency
• anomaly is sensitive to pendulum phasing - ie. if one's cranked 180° to the other, anomaly doesn't grow to significance
So, nothing exciting or remotely useful for now, prolly sim error, i expect from insufficiently-precise angular-linear conversion factors in the spool code (not quite enough rotation angle applied per drop height?).. Not worth much time or effort, and it ain't like we're unaware this software has limits.. but if it were a 1 J gain in 225 - and real - that'd be worth mining, so it'd be good to resolve now, just to get a handle on an error source that could set off a wild goose chase later..
ETA: incidentally, i initially only metered the GPE of the drop weight, assuming no net change in GPE was possible on the wheel; upon seeing the error tho, i re-did the GPE code to measure that of every single mass in the sim.. was hoping that'd reveal the error source as the pendulum displacements, however as you'd expect they're a zero sum, so metering the drop-weight GPE alone is sufficient to reproduce the anomaly..
(Other simmers, hit ctrl-A to 'select all' then double-click 'show' in the 'Appearance' widget to reveal everything - there's an MoI calc for calibrating the pendulum masses, and the GPE meter sits on top of three more hidden ones, since the net GPE equation for every mass in the sim is too long to fit into a single meter. Additionally, i wanted to be able to spool the weight off either wheel for comparison, so attached one to each and just pinned one to the background with its rope deactivated, rather than having to keep rewriting the equations - you can swap between 'em, activate both at once or neither.)
• the pendulums each have the same MoI as the blue flywheel they're cranking
As mentioned, i was investigating opportunities for causing an asymmetric internal distribution of momentum sourced from gravity (still ongoing).
• when the weight spools off the outer wheel instead, we still see a small anomaly but it never grows to significance
• this is almost certainly sim error, and even then, 1 J in 225 should harldy prick interest
• the sim's set to pause whenever the error reaches <= 1 J - it seems to be ramping up by that point tho, climbing in ever-larger discrete jumps..
..this last point should help with debugging presumably..
• the only potentially-lossy component here is the rope, being set to '0' elasticity, however i don't see why it should be dissipating anything under these conditions..
• the loss seems to increment most significantly as the pendulums change direction..
• could be a rounding error in the angular-to-linear conversion constants?
• anomaly appears unchanged by raising sim frequency
• anomaly is sensitive to pendulum phasing - ie. if one's cranked 180° to the other, anomaly doesn't grow to significance
So, nothing exciting or remotely useful for now, prolly sim error, i expect from insufficiently-precise angular-linear conversion factors in the spool code (not quite enough rotation angle applied per drop height?).. Not worth much time or effort, and it ain't like we're unaware this software has limits.. but if it were a 1 J gain in 225 - and real - that'd be worth mining, so it'd be good to resolve now, just to get a handle on an error source that could set off a wild goose chase later..
ETA: incidentally, i initially only metered the GPE of the drop weight, assuming no net change in GPE was possible on the wheel; upon seeing the error tho, i re-did the GPE code to measure that of every single mass in the sim.. was hoping that'd reveal the error source as the pendulum displacements, however as you'd expect they're a zero sum, so metering the drop-weight GPE alone is sufficient to reproduce the anomaly..
- Attachments
-
- new_track.wm2d
- (34.15 KiB) Downloaded 55 times
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Re: re: Decoupling Per-Cycle Momemtum Yields From RPM
Cheers again mate - all the maths boil down to is the KE formula - half the mass times the velocity squared - and momentum as mass times velocity; the distinction being that the latter is always conserved in interactions between bodies in spite of their respective mass and velocity distributions, while the former may only be partially conserved as its slightly-different function of those same 'mass' and 'velocity' components..silent wrote:Great post MrV and even though I get lost in the math, I still have to say that the 75% loss 25% gain matches what circle said on overunity.com when he said that .2 to .25 of the weight set is left hanging out in thin air - the part that actually drives the wheel...one weight of the pair of pairs.
Love your work!
silent
..so for a closed-system example if net speed halves, net inertia must've doubled (because momentum's conserved), and per ½mV² twice the inertia at half the velocity has half the energy.. the other half of which must've been dissipated by whatever caused the inertia to double.
If, in an otherwise-closed system of interacting masses we can somehow apply a unilateral momentum rise to one mass only, then its speed has changed relative to the others, and it must collide back with them if we want to keep repeating the cycle, redistributing its momentum rise in the process, by slowing itself down a bit, but speeding everything else up a bit to conserve that new net momentum; when that mass sped up unlaterally, it broke PE-KE symmetry, but when it then collided back with the other masses it lost at least half its speed, and so 75% of its energy, basically quartering it per V², whilst holding onto that 25% remainder.
Because all of the momentum's conserved, and the net inertia's constant, net velocity must rise each cycle, progressively inflating the KE value of that 25% conserved PE over successive cycles, and because KE squares with velocity, the returns - and OU efficiency - keep on rising with RPM.
So, just two formulas - p=mV and KE = ½mV², where 'mass' and 'inertia' are functionally interchangeable (angular KE = ½Iw², where 'w' is angular velocity). Mass times velocity for one, half that squared for the other.. and this 75% loss / 25% gain dynamic just falls out of the unilateral momentum rises and their consolidating impacts..
What really encourages is that there's obviously no way Bessler could've understood the significance of the "5 cycs to OU" envelope unless he'd already solved the momentum / work dichotomy for himself, decades prior to its scientific consensus.. but that equally, it formed only the set-up for his complete IP, hence it never got to peer review.. even tho he was personal friends with Leibniz and 's Gravesande, the chief architects of the vis viva dispute's final resolution!
Think about what that means for a second; he surely couldn't simply have worked it all out from 1st principles alone (both Newton and Leibniz got it wrong initially!) - his insights were obviously experimentally-led, not a priori revelations - rather, he must've developed it by exhaustively and comprehensively investigating the gain principle, and reducing his discovery to its elements; in short, how much bang for buck you can accrue when your net input work no longer depends upon torquing against - and thus, wheel speed relative to - a stator..
He basically couldn't've faked it, the 25% accumulator / 5 cycs to OU route is a proven result and he's describing it, not some kind of esoteric prediction that just happens to perfectly correlate with an actual gain cycle plotted out using a standard model of mechanics that didn't exist yet..
We're on the right path.
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Cleaned up the spool code in that GPE anomaly.
Previously, the attachment point from which the rope spools off the reel used the following code:
X: 1.00000e-002*(body[13].radius *1.00000e+002* cos((body[13].p.r *5.72958e+001 +180) * 1.7453e-002))
Y: 1.00000e-002*(body[13].radius *1.00000e+002* -sin((body[13].p.r *5.72958e+001 +180) * 1.7453e-002))
Since getting this technique off Fletcher i've basically been cut'n'pasting it, just changing the body names and angular offsets as required..
..but looking at all the redundancies and limited conversion constants, i'm evidently guilty of some cargo-cult programming there..
When initially selecting a new sim's accuracy settings, i always increase the number of internally-used digits to its maximum of '16'..
..however since the radian / degree conversion constants are functions of Pi, and hence non-rational, we want to formulate the equation in such a way that the most accurate-possible conversion factors are calculated on the fly as a function of whatever the available floating point precision - and besides, typing multiple 16-digit constants into the same equation is hardly elegant - so why not just reference the formulas that produce the constants instead?
For instance "5.72958e+001" = 57.2958 - much shorter way of expressing it - and is obviously referencing 180° / Pi.. so why not just replace it with "(180/Pi)"? It's even shorter, and likely to churn out many more significant digits for any calcs depending on its precision..
Similarly, at the front end of the equation, one-hundreth of the reel's radius is immediately multiplied by 100.. an utterly pointless waste of CPU cycles!
And just as "5.72958e+001" can be improved by "(180/Pi)", so "1.7453e-002" is better expressed as simply "(Pi/180)"!
Duh!?
And so the attachment point code actually reduces to:
X: (body[13].radius*cos((body[13].p.r*(180/Pi)+180)*(Pi/180)))
Y: (body[13].radius*-sin((body[13].p.r*(180/Pi)+180)*(Pi/180)))
Likewise, the rope's length-control portion of the code previously looked like this:
Length: 1.00000e-002*(100 + body[13].p.r *5.72958e+001* body[13].radius *1.00000e+002* 2 * Pi / 360)
But has now been reduced to this:
Length: (1+body[13].p.r*(180/Pi)*body[13].radius*2*Pi/360)
The first digit '1' is the initial rope length in meters, which then changes by the circumference of the reel's angular displacement.
So let's run it and see if it cleans up the result:
Well the error definitely creeps in later in the run, so it's stable up to a higher speed..
..yet it still ramps up quickly past a threshold RPM, reaching -1 J at 230 J throughput, so only 5 J later than using the old code.. not a great improvement, then..
None of this matters of course, just good opportunity to see the sim limits laid bare, trying workarounds etc.
I think in this case, the code can't be made any more efficient or accurate-in-principle, and if the error's also impervious to higher sim freqs then there's little else to do but make note of the failure conditions and try to avoid or just remain aware of them in future..
Previously, the attachment point from which the rope spools off the reel used the following code:
X: 1.00000e-002*(body[13].radius *1.00000e+002* cos((body[13].p.r *5.72958e+001 +180) * 1.7453e-002))
Y: 1.00000e-002*(body[13].radius *1.00000e+002* -sin((body[13].p.r *5.72958e+001 +180) * 1.7453e-002))
Since getting this technique off Fletcher i've basically been cut'n'pasting it, just changing the body names and angular offsets as required..
..but looking at all the redundancies and limited conversion constants, i'm evidently guilty of some cargo-cult programming there..
When initially selecting a new sim's accuracy settings, i always increase the number of internally-used digits to its maximum of '16'..
..however since the radian / degree conversion constants are functions of Pi, and hence non-rational, we want to formulate the equation in such a way that the most accurate-possible conversion factors are calculated on the fly as a function of whatever the available floating point precision - and besides, typing multiple 16-digit constants into the same equation is hardly elegant - so why not just reference the formulas that produce the constants instead?
For instance "5.72958e+001" = 57.2958 - much shorter way of expressing it - and is obviously referencing 180° / Pi.. so why not just replace it with "(180/Pi)"? It's even shorter, and likely to churn out many more significant digits for any calcs depending on its precision..
Similarly, at the front end of the equation, one-hundreth of the reel's radius is immediately multiplied by 100.. an utterly pointless waste of CPU cycles!
And just as "5.72958e+001" can be improved by "(180/Pi)", so "1.7453e-002" is better expressed as simply "(Pi/180)"!
Duh!?
And so the attachment point code actually reduces to:
X: (body[13].radius*cos((body[13].p.r*(180/Pi)+180)*(Pi/180)))
Y: (body[13].radius*-sin((body[13].p.r*(180/Pi)+180)*(Pi/180)))
Likewise, the rope's length-control portion of the code previously looked like this:
Length: 1.00000e-002*(100 + body[13].p.r *5.72958e+001* body[13].radius *1.00000e+002* 2 * Pi / 360)
But has now been reduced to this:
Length: (1+body[13].p.r*(180/Pi)*body[13].radius*2*Pi/360)
The first digit '1' is the initial rope length in meters, which then changes by the circumference of the reel's angular displacement.
So let's run it and see if it cleans up the result:
Well the error definitely creeps in later in the run, so it's stable up to a higher speed..
..yet it still ramps up quickly past a threshold RPM, reaching -1 J at 230 J throughput, so only 5 J later than using the old code.. not a great improvement, then..
None of this matters of course, just good opportunity to see the sim limits laid bare, trying workarounds etc.
I think in this case, the code can't be made any more efficient or accurate-in-principle, and if the error's also impervious to higher sim freqs then there's little else to do but make note of the failure conditions and try to avoid or just remain aware of them in future..
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
re: Decoupling Per-Cycle Momemtum Yields From RPM
OK so it looks like i may have a fully-consistent contender of a theory here:
• Bessler kept working these bloody pendulums into his published prints for a reason.. and we know it wasn't historical accuracy!
In particular, he keeps showing us this type of interaction:
So an output GPE spins up a wheel, cranking a pendulum..
I suspect this may be showing us the principle of splitting an output GPE's momentum into a constant motion, alongside an alternating one; ie. momentum from gravity is being harnessed, and half of it is alternating in sign every swing of the pendulum.
The point is that the momenta go in the same directions, then alternate, in turn.
But this is only half a mechanism..
On the right-side pane, note the support post connects to both floor and ceiling, via brackets - these show that no trickery is conducted through the support posts.. that the system is isolated.. ;)
Those brackets lead us to the next image:
Brackets still numbered "10" here, tho everything else uses letters..
Same deal tho - bucket spooling off axle, turns wheel one way, water-screw the other..
..but using that square pulley, hence water rises in fits and starts, dwelling back down after each 'pump'..
..so the water's mass is alternating direction through the screw..
The pendulums here are functionally relegated, and the stampers, observed in detail, are only good for falling 'outwards' as if gravity were alternating in direction, or else, were actually CF force..
Could the winning gig be something like "generate momentum + counter-momentum from gravity, invert the sign of half of it, and then mutually cancel the inverted half, accumulating the remains"?
The water draining away; if indeed this represents the 25% p-c efficiency accumulator, then ¾ of the GPE output by the spooling bucket has been dissipated, either by the water, or stampers..
Now notice the bracket on the left-side wall - this detail leads us into the next image, and the same principles seem to apply here:
• that carried-over wall bracket now suspends / isolates the support posts and framework holding the wheel, implying everything in the left pane is mobile about that axis; the penduli are behind their 'hangars'
• box of bricks drops, applying the m-from-the-G
• penduli alternate the sign of half of it
•• stampers somehow dissipate / cancel the inverted half??
But how could a linear impact with the rim dissipate angular momentum, right? I mean, it can't be dissipated - you could perform some useless work to burn off the KE, but the momentum must be getting sunk somewhere - either to earth, via the support posts, or via gravity..
No, i don't quite get it either, yet it seems to be a persistent implication that counter-momentum is being somehow self-cancelled with an otherwise-superfluous dissipative workload!
Yet mechanically, the implications are bare - if the box of bricks is being lifted, then the stampers must be falling upwards, and something must be pushing them back down; either gravity's rotating, or we're dealing with CF force again.
If as suspected the rope passing through that same quadrant of the window pane represents the 25% accumulator indicated by the Toys page, then the interaction behind it must somehow 'dissipate' all of the counter-momentum..
Here's that key detail from the Toys page:
• two impetuses from left-to-right, or say clockwise
• only one going back from right-to-left / CCW
And five of these cycles result in something extraordinary..
So, what if the upper hammer toy represents an output of momentum from gravity?
And the lower one alternates the sign of half of it, and grounds / mutually cancels it..
So cycle #1 collects say 1 kg-m²-rad/s of momentum from gravity for 1 J; half of that gets inverted and self-cancelled (?) so we've half a J left, then the remaining momentum gets redistributed between the two bodies (wheel and pendulum) which halves the remaining KE again; hence ¼ remaining and ¾ dissipated.. and the net system's gained ½ kgm²-rad/s.
Four of those make unity, five makes 125%.
So those basic steps again:
• collect momentum from gravity
• isolate half of it (the counter-momentum?) and use something like a cranked pendulum / weight lever to invert half of that, then mutually cancelling both / sacrificing their KE with an otherwise-needless dissipative workload
• with half of the first cycle's m-from-G remaining, and one quarter of its input energy, just keep repeating the cycle, for 125% at the fifth
This is what's being implied, is it not? It seems to tie all the clues into a coherent physical principle - ie. it's not the absolute quantity of m-from-G you can grab each cycle - which will inevitably always be RPM dependent - but simply how it's apportioned internally; if all counter-momenta can be mutually self-cancelled each cycle then each is 25% efficient, but net PE-to-KE efficiency keeps increasing by 25% each cycle regardless of the fact that the total per-cycle yield's decreasing as RPM's rise..
• Bessler kept working these bloody pendulums into his published prints for a reason.. and we know it wasn't historical accuracy!
In particular, he keeps showing us this type of interaction:
So an output GPE spins up a wheel, cranking a pendulum..
I suspect this may be showing us the principle of splitting an output GPE's momentum into a constant motion, alongside an alternating one; ie. momentum from gravity is being harnessed, and half of it is alternating in sign every swing of the pendulum.
The point is that the momenta go in the same directions, then alternate, in turn.
But this is only half a mechanism..
On the right-side pane, note the support post connects to both floor and ceiling, via brackets - these show that no trickery is conducted through the support posts.. that the system is isolated.. ;)
Those brackets lead us to the next image:
Brackets still numbered "10" here, tho everything else uses letters..
Same deal tho - bucket spooling off axle, turns wheel one way, water-screw the other..
..but using that square pulley, hence water rises in fits and starts, dwelling back down after each 'pump'..
..so the water's mass is alternating direction through the screw..
The pendulums here are functionally relegated, and the stampers, observed in detail, are only good for falling 'outwards' as if gravity were alternating in direction, or else, were actually CF force..
Could the winning gig be something like "generate momentum + counter-momentum from gravity, invert the sign of half of it, and then mutually cancel the inverted half, accumulating the remains"?
The water draining away; if indeed this represents the 25% p-c efficiency accumulator, then ¾ of the GPE output by the spooling bucket has been dissipated, either by the water, or stampers..
Now notice the bracket on the left-side wall - this detail leads us into the next image, and the same principles seem to apply here:
• that carried-over wall bracket now suspends / isolates the support posts and framework holding the wheel, implying everything in the left pane is mobile about that axis; the penduli are behind their 'hangars'
• box of bricks drops, applying the m-from-the-G
• penduli alternate the sign of half of it
•• stampers somehow dissipate / cancel the inverted half??
But how could a linear impact with the rim dissipate angular momentum, right? I mean, it can't be dissipated - you could perform some useless work to burn off the KE, but the momentum must be getting sunk somewhere - either to earth, via the support posts, or via gravity..
No, i don't quite get it either, yet it seems to be a persistent implication that counter-momentum is being somehow self-cancelled with an otherwise-superfluous dissipative workload!
Yet mechanically, the implications are bare - if the box of bricks is being lifted, then the stampers must be falling upwards, and something must be pushing them back down; either gravity's rotating, or we're dealing with CF force again.
If as suspected the rope passing through that same quadrant of the window pane represents the 25% accumulator indicated by the Toys page, then the interaction behind it must somehow 'dissipate' all of the counter-momentum..
Here's that key detail from the Toys page:
• two impetuses from left-to-right, or say clockwise
• only one going back from right-to-left / CCW
And five of these cycles result in something extraordinary..
So, what if the upper hammer toy represents an output of momentum from gravity?
And the lower one alternates the sign of half of it, and grounds / mutually cancels it..
So cycle #1 collects say 1 kg-m²-rad/s of momentum from gravity for 1 J; half of that gets inverted and self-cancelled (?) so we've half a J left, then the remaining momentum gets redistributed between the two bodies (wheel and pendulum) which halves the remaining KE again; hence ¼ remaining and ¾ dissipated.. and the net system's gained ½ kgm²-rad/s.
Four of those make unity, five makes 125%.
So those basic steps again:
• collect momentum from gravity
• isolate half of it (the counter-momentum?) and use something like a cranked pendulum / weight lever to invert half of that, then mutually cancelling both / sacrificing their KE with an otherwise-needless dissipative workload
• with half of the first cycle's m-from-G remaining, and one quarter of its input energy, just keep repeating the cycle, for 125% at the fifth
This is what's being implied, is it not? It seems to tie all the clues into a coherent physical principle - ie. it's not the absolute quantity of m-from-G you can grab each cycle - which will inevitably always be RPM dependent - but simply how it's apportioned internally; if all counter-momenta can be mutually self-cancelled each cycle then each is 25% efficient, but net PE-to-KE efficiency keeps increasing by 25% each cycle regardless of the fact that the total per-cycle yield's decreasing as RPM's rise..
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
-
- Devotee
- Posts: 1718
- Joined: Fri Nov 07, 2003 12:22 pm
- Location: Speyer, Germany
- Contact:
re: Decoupling Per-Cycle Momemtum Yields From RPM
Hi MrVibrating,
what you see in MT138 is a top heavy pendulum.
The upper figures are heavier than the bottom ones.
To prevent a fall over and allow a reswing you must extract energy.
It is a mechanical SR flip flop, look how they are switched.
https://en.wikipedia.org/wiki/Flip-flop_(electronics)
what you see in MT138 is a top heavy pendulum.
The upper figures are heavier than the bottom ones.
To prevent a fall over and allow a reswing you must extract energy.
It is a mechanical SR flip flop, look how they are switched.
https://en.wikipedia.org/wiki/Flip-flop_(electronics)
Best regards
Georg
Georg
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
I am quite certain that what all of the aforementioned images are depicting is a pair of opposing angular accelerations coupled to a central radial one.
Note that the upper hammer toy aligns neatly to one side of the axis as represented by the eyelets running down either side, whereas the lower hammer toys just as deliberately aligns in-between opposing eyelets - in other words, the two interactions the toys represent are in orthogonal alignment, and this minimum mechanism thus has a cross-shape..
• consider a stamper that drops through the axle
• so, angular lift, radial drop
• the purpose of this action is the resulting inertial torques:
•• as the stamper drops from the top position into the central position, MoI is decreasing, so RPM's increase to maintain angular momentum
•• as the stamper continues down from the center to the bottom position, MoI is restored so speed likewise decelerates
• so basically a radial drop causes a positive then negative inertial torque pair, breifly speeding then slowing the rotation
• couple that radial drop to a pair of opposing weight levers
• the purpose of the weight levers is to garner a clockwise vs counter-clockwise, up vs down G*t asymmetry
• crucially, if these weight levers are the diametric kind - pivoting to opposite sides of the rim, rather than to the center - then the positive inertial torques from the stamper drop will raise the axis of the falling lever weight, while lowering that of the rising one..
• this increases the drop period of the falling weight, while cutting that of the rising one, resulting in a positive closed-loop G*t delta
• the FoR of the stamper is rotating with the wheel - ie. the lever weights are not going to be synced to external coordinate space, hence the per-cycle momentum yield should be impervious to RPM!
The stamper could bounce on a spring instead of dissipating KE on each landing - in which case we'd be paying a constant input GPE to rotate it upwards on each lift..
..but since the exact angle at which it drops will be allowed to drift - adapting with changing RPM - and the radial drop time itself is already isolated from RPM, the constant GPE input should hopefully generate a constant +/- G*t delta across some useful RPM range..
Pretty certain this is what a 'cross piece' comprises. All the clues are pointing the same way - MT 41 / 42 et al, MT 133 / 134, the Merseburg / Kassel prints, the Toys page.. this is the consistent link; as much with the implicit physics of OU, as schematically / figuratively.
Statorless angular momentum can only come from a +/- G*t asymmetry, and to be OU its energy cost of accumulation must be speed-invariant. This could potentially be a means of achieving that..
Note that the upper hammer toy aligns neatly to one side of the axis as represented by the eyelets running down either side, whereas the lower hammer toys just as deliberately aligns in-between opposing eyelets - in other words, the two interactions the toys represent are in orthogonal alignment, and this minimum mechanism thus has a cross-shape..
• consider a stamper that drops through the axle
• so, angular lift, radial drop
• the purpose of this action is the resulting inertial torques:
•• as the stamper drops from the top position into the central position, MoI is decreasing, so RPM's increase to maintain angular momentum
•• as the stamper continues down from the center to the bottom position, MoI is restored so speed likewise decelerates
• so basically a radial drop causes a positive then negative inertial torque pair, breifly speeding then slowing the rotation
• couple that radial drop to a pair of opposing weight levers
• the purpose of the weight levers is to garner a clockwise vs counter-clockwise, up vs down G*t asymmetry
• crucially, if these weight levers are the diametric kind - pivoting to opposite sides of the rim, rather than to the center - then the positive inertial torques from the stamper drop will raise the axis of the falling lever weight, while lowering that of the rising one..
• this increases the drop period of the falling weight, while cutting that of the rising one, resulting in a positive closed-loop G*t delta
• the FoR of the stamper is rotating with the wheel - ie. the lever weights are not going to be synced to external coordinate space, hence the per-cycle momentum yield should be impervious to RPM!
The stamper could bounce on a spring instead of dissipating KE on each landing - in which case we'd be paying a constant input GPE to rotate it upwards on each lift..
..but since the exact angle at which it drops will be allowed to drift - adapting with changing RPM - and the radial drop time itself is already isolated from RPM, the constant GPE input should hopefully generate a constant +/- G*t delta across some useful RPM range..
Pretty certain this is what a 'cross piece' comprises. All the clues are pointing the same way - MT 41 / 42 et al, MT 133 / 134, the Merseburg / Kassel prints, the Toys page.. this is the consistent link; as much with the implicit physics of OU, as schematically / figuratively.
Statorless angular momentum can only come from a +/- G*t asymmetry, and to be OU its energy cost of accumulation must be speed-invariant. This could potentially be a means of achieving that..
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Since i'm going to be playing with diametric levers again, there's one quick interaction i want to check:
• the two levers take turns to lift the OB weight
• both thus lift in the same direction, counter to the rotation
• the counter-momentum from each lift is thus in the OB direction
The implementation here's crude, but adequate to the task; activating and deactivating pin joints on the ends of each lever to pick up and drop the weight at specified frame intervals.
The potential exploit being investigated here is that lifting the weight only ever applies counter-momentum to the wheel in the same direction that it's over-balancing.
Obviously however, those counter-momenta only exist when the weight's actually rising, and cease when the lift ends, mutually cancelling..
Thus the input energy - the main workload on the motor (one motor drives both levers via a gear link) - is simply the input GPE, the output energy is the GKE, no additional momentum from gravity has been obtained, the per-cycle momentum yield is purely from OB torque hence tracking sqrt(w), per ½Iw², with a small dissipative loss from the catch-and-release.
So the system i want to look at next probably wants longer levers - making use of the full diameter - having smaller swinging arcs, and connecting to a central radial 'stamper' (basically a radially-dropping mass), to act as a simple automatic vMoI..
The positive inertial torque as it drops into the central MoI minimum will briefly accelerate the wheel - and thus the lever axes - around the weights on their ends, and rotating in opposite directions, one lever weight will thus see an increased G-time, while the others' is proportionately decreased..
..and that's the basic hoped-for exploit, if you can see it - ie.:
• if the weight levers pivoted at the wheel's central axis, then their pivots never change height
• if instead their pivots have positive radius - ie. outside the center, but on the same side the weights drop (so, 'radial levers') - then their axes are moving in the same vertical direction as their weights
• ..and so uniquely, with diametric levers (ie. having 'negative radius'), the pivots move in the opposite vertical direction to the weights
Essentially then it's a case of moving the rug under the weights in flight, raising the effective per-cycle G-time of one, while cutting that of the other.
The hope is that because this action will be synced by the radial drop of a 'stamper' GPE / vMoI, it'll track around with the system as RPMs change, instead of being rigidly synced to absolute wheel angle relative to coordinate space.
Thus the possibility of constant per-cycle G*t yields over some range of RPM..
• the two levers take turns to lift the OB weight
• both thus lift in the same direction, counter to the rotation
• the counter-momentum from each lift is thus in the OB direction
The implementation here's crude, but adequate to the task; activating and deactivating pin joints on the ends of each lever to pick up and drop the weight at specified frame intervals.
The potential exploit being investigated here is that lifting the weight only ever applies counter-momentum to the wheel in the same direction that it's over-balancing.
Obviously however, those counter-momenta only exist when the weight's actually rising, and cease when the lift ends, mutually cancelling..
Thus the input energy - the main workload on the motor (one motor drives both levers via a gear link) - is simply the input GPE, the output energy is the GKE, no additional momentum from gravity has been obtained, the per-cycle momentum yield is purely from OB torque hence tracking sqrt(w), per ½Iw², with a small dissipative loss from the catch-and-release.
So the system i want to look at next probably wants longer levers - making use of the full diameter - having smaller swinging arcs, and connecting to a central radial 'stamper' (basically a radially-dropping mass), to act as a simple automatic vMoI..
The positive inertial torque as it drops into the central MoI minimum will briefly accelerate the wheel - and thus the lever axes - around the weights on their ends, and rotating in opposite directions, one lever weight will thus see an increased G-time, while the others' is proportionately decreased..
..and that's the basic hoped-for exploit, if you can see it - ie.:
• if the weight levers pivoted at the wheel's central axis, then their pivots never change height
• if instead their pivots have positive radius - ie. outside the center, but on the same side the weights drop (so, 'radial levers') - then their axes are moving in the same vertical direction as their weights
• ..and so uniquely, with diametric levers (ie. having 'negative radius'), the pivots move in the opposite vertical direction to the weights
Essentially then it's a case of moving the rug under the weights in flight, raising the effective per-cycle G-time of one, while cutting that of the other.
The hope is that because this action will be synced by the radial drop of a 'stamper' GPE / vMoI, it'll track around with the system as RPMs change, instead of being rigidly synced to absolute wheel angle relative to coordinate space.
Thus the possibility of constant per-cycle G*t yields over some range of RPM..
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
..so this is basically gonna be another MT 40-ish, with the following alterations:
• use leaf springs, per MT 18, for the diametric weight levers, thus allowing them to sag on the ascending side, and so incorporating a basic GPE-cycling system; the inertial torques from the MoI changes will thus load / unload the springs as their axes briefly accelerate ahead of the rotation
• use a pair of rigidly-connected weights (as by a rod) alternating between central / rim positions for the 'stamper', thus maximising the MoI variation and any resulting G*t delta
It's gonna be a case of carefully metering the changing distribution of angular momentum between the sprung-levers and wheel base / vMoI 'stamper' weights..
• use leaf springs, per MT 18, for the diametric weight levers, thus allowing them to sag on the ascending side, and so incorporating a basic GPE-cycling system; the inertial torques from the MoI changes will thus load / unload the springs as their axes briefly accelerate ahead of the rotation
• use a pair of rigidly-connected weights (as by a rod) alternating between central / rim positions for the 'stamper', thus maximising the MoI variation and any resulting G*t delta
It's gonna be a case of carefully metering the changing distribution of angular momentum between the sprung-levers and wheel base / vMoI 'stamper' weights..
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Made a nice leaf spring:
19x 10 cm lengths of steel connected by rotary springs, with 1.9x the set spring constant at the thick end, graduating down to 1.1x at the thin end.
So, an opposing pair of these, swung by a central radial 'stamper' GPE; let 'em sag on the rising side, falling flat onto a rimstop on the OB side.
The radial GPE will cause a momentary MoI drop and corresponding reactionless acceleration of the spring's axes, altering their respective +/- G-times and so hopefully yielding a clockwise / counter-clockwise momentum-from-gravity asymmetry that doesn't decrease with RPM.
Years i've been staring at this MT-40-ish interaction - seriously, it's what all the clues consistently point back to - but this time i'm finally coming at it from a completely independent deduction from 1st principles - all of B's stuff resolves back to this system, but so does all the implicit mechanical physics of OU; constant momentum cost invariant of RPM, no other form of mechanical OU is even conceptually feasible..
Freeing the system sync from any dependence upon external / absolute coordinate space, whilst isolating the central GPE from the rising / falling edge speeds of the wheel, should be ticking all the right boxes by my reckoning..
19x 10 cm lengths of steel connected by rotary springs, with 1.9x the set spring constant at the thick end, graduating down to 1.1x at the thin end.
So, an opposing pair of these, swung by a central radial 'stamper' GPE; let 'em sag on the rising side, falling flat onto a rimstop on the OB side.
The radial GPE will cause a momentary MoI drop and corresponding reactionless acceleration of the spring's axes, altering their respective +/- G-times and so hopefully yielding a clockwise / counter-clockwise momentum-from-gravity asymmetry that doesn't decrease with RPM.
Years i've been staring at this MT-40-ish interaction - seriously, it's what all the clues consistently point back to - but this time i'm finally coming at it from a completely independent deduction from 1st principles - all of B's stuff resolves back to this system, but so does all the implicit mechanical physics of OU; constant momentum cost invariant of RPM, no other form of mechanical OU is even conceptually feasible..
Freeing the system sync from any dependence upon external / absolute coordinate space, whilst isolating the central GPE from the rising / falling edge speeds of the wheel, should be ticking all the right boxes by my reckoning..
-
- Devotee
- Posts: 1718
- Joined: Fri Nov 07, 2003 12:22 pm
- Location: Speyer, Germany
- Contact:
re: Decoupling Per-Cycle Momemtum Yields From RPM
MrVibrating wrote:
Axis of rotation of the masses and wheel axis are not identical.
So we have 2 independent axis.
Center of mass is not the center of the wheel
For me this description is a loose axle.Freeing the system sync from any dependence upon external / absolute coordinate space, whilst isolating the central GPE from the rising / falling edge speeds of the wheel, should be ticking all the right boxes by my reckoning..
Axis of rotation of the masses and wheel axis are not identical.
So we have 2 independent axis.
Center of mass is not the center of the wheel
Best regards
Georg
Georg
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
When modelling springs connected to other springs, WM can rapidly whip up CTD-inducing infinities, so lots of integration steps are required for stable operation; this can be done by raising frequency, at the expense of both sim period and real time, or much more quickly by raising the number of integration steps per frame; here i've raised it to '10':
The spring constant's now been raised, and the bob weight also, enough to produce OB on that side.
A zero-elasticity rope serves as an efficient 'rim-stop', providing an inelastic collision without modelling needlessly CPU-intensive surface contacts / overlaps.
So next i'll want an opposing pair of these - maybe with a y-offset between 'em just to keep the picture clear.. technique seems good, should be able to have 'em as pert or droopy as required..
The spring constant's now been raised, and the bob weight also, enough to produce OB on that side.
A zero-elasticity rope serves as an efficient 'rim-stop', providing an inelastic collision without modelling needlessly CPU-intensive surface contacts / overlaps.
So next i'll want an opposing pair of these - maybe with a y-offset between 'em just to keep the picture clear.. technique seems good, should be able to have 'em as pert or droopy as required..
-
- Addict
- Posts: 2879
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Re: re: Decoupling Per-Cycle Momemtum Yields From RPM
You're almost there; it's about having two independent frames of reference - the output KE will always reside in the external FoR, by definition..Georg Künstler wrote:MrVibrating wrote:
For me this description is a loose axle.Freeing the system sync from any dependence upon external / absolute coordinate space, whilst isolating the central GPE from the rising / falling edge speeds of the wheel, should be ticking all the right boxes by my reckoning..
Axis of rotation of the masses and wheel axis are not identical.
So we have 2 independent axis.
Center of mass is not the center of the wheel
..and usually, the input PE would also be in that same FoR, this being the condition that causes PE-KE symmetry.
But if the PE is in an accelerating FoR, then the KE value of work within is inflated by the ambient speed of the system relative to the ground FoR.
Energy squares with velocity, yet for this same reason, scales linearly when we accumulate momentum in small discrete accelerations each starting from relative stasis; hence 10 purchases of 1 kg-m/s at ½ J each has a net cost of 5 J, yet could leave us with 1 kg at 10 m/s and thus 50 J of KE, so 10x OU.
That's how you make energy.
Input energy in one velocity FoR..
..and output energy in another.
The 3rd and 1st laws of motion normally preclude such interactions.
But momentum sourced from G*t obviates any need for a stator, or, thus, rising velocity (and thus squaring energy cost) in relation to that stator.
So here i'm attempting to fix the input energy cost of buying system angular momentum from gravity and time, thus expending less input work than output KE.
Normally, the faster the RPM's, the lower the gravity-time and thus momentum change per cycle. Diminishing returns.
The only possible solution is EMGAT; all of the internal parts and perpetual motion structures maintain the power of free movement, as i've been saying since 17:12 yesterday afternoon.