Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

In WM2D, is it possible with scripts to turn the motor off at a certain point within a certain
range while holding the weight by turning a rod on as Jonathan suggested so many years
ago?

Latch it that way.

That's still just an inelastic collision, and still wastes energy that then needs recouping.

Like i say, it would seem better to brake them by using them to cooperate in a lifting effort, that results in them being relatively stationary again, and also having raised a weight.. engineering out the inelastic collision is the logical way to go, since the gain's already there beforehand..

A collision's only really essential if the FoR acceleration needs to accumulate over successive cycles (per the Toys Page interaction). Here it's incidental to the actual velocity deltas.

And in the latest result, the principle's so mechanically simple it'll be a piece of piss to harness..

[MrVibrating]

Especially one that's designed to make the values balance.

That's not how sims work. It's not how WM works. It's not how maths or science works. It's just your usual BS.

The sim has no clue what the T*a integral even is - it has to be calculated outside the sim, in a spreadsheet. So your theory requires that WM can know in advance what Excel is going to output from that Riemann sum..

It's bollocks innit? The sim just calculates torque as a function of I*rad/s² over successive frames of time, and records those values as a long list of numbers, which can then be used to plot a graph or calculate the energy under the curve or whatever. It doesn't and cannot modify those independent force values to maintain CoE - and if it somehow could and did, then it'd evdently not be doing it very well, right about now..

Ehm nope, sorry.

Your KE rise is 51.2556 Joules
Part comes from the green bob pendulum that drops its GPE (19.6133 J).
This may increase stuff temporarily for this first half cycle, but it's also needed to bring it back up again for the second half cycle.
So you're left with 51.2556-19.6133 = 31.6423 Joules that comes from the motor that creates the 10rad/s difference.
Than with the inelastic clash it loses: 25 Joules.
A hint (for others):
E.start= ½I·(ω-5)²+½I·(ω+5)²
Momentum clash and conservation I·(ω-5) + I·(ω+5) := (I+I)·(ω+5+w-5)
E.end = ½I·(ω)²+½I·(ω)²
Difference: 2·½·5²


31.6423 - 25 = 6.6423 Joules
Ready to perform an increase in angular velocity per cycle.

That's not even logically consistent!?

You've simply assumed a priori that the difference between the KE rise and GPE output was motor work - ignoring the T*a integral entirely!?

What's the point of measuring the T*a efficiency if you're just going to ignore it and assume it's 100% efficient, even though the measurement says it's OU? Are you completely insane? You've simply assumed the input energy instead of fucking measuring it!


Besides which, the point of calculating the peak KE at BDC is that the frickin' 'bang' is redundant - it's tolerable for low values of TRS but only for cheap demo's / desktop toys - and incidental to re-equalising the speeds, which could instead be harnessed directly as T*a, and to much greater relative speeds and thus efficiencies, so i wanted to see how much energy there is to raise some GPE at that point in the cycle; the GPE in question could be a radial lift of the 'stator' weight (the 'bob') itself, remember..

If this second route's a goer tho, even you won't be able to fuck up the calcs (tho doubtless if there is a way, you'll find it)..

You can't just fucking deduce the T*a integral by deducting the GPE output from the KE rise tho, you fucking clownshoes.. LOL i mean how the fuck.. why am i running overnight sims at stupid precisions and crunching 32,000 data points per measurement when i could just infer the input energy by simply assuming unity? Because that's the easy way, right? The easy way to find OU. Just assume everything's at unity. That'll work. Everyone's an idiot but Marchello. He's got this thing sussed.

Derp.

[Fletcher]

Naah .. he's simply saying use as many practical cross-check methods in the sim as you can. If it can be done one way, try another comparable way e.g. his springs suggestion (even if you don't agree it's comparable).

You already tried the actuator and motor options.

If the results are consistent across the board then maybe there's something to it. If not then maybe the programing is awry. Not accounting for something or over-accounting ? Doesn't appear to be top-down COE dependent software from your results.

ATEOTD to prove the hypothesis a practical physical build will be required. I know it's too early to go there but it shouldn't stop any of us from thinking about what physical devices we could employ in the sim and real world test of the sim. Then each could be tweaked against the other for that comparison and educational purposes.

JMO's.

[MrVibrating]

Re-took that last result at higher precision:



..still massively OU, but why does the torque plot have that weird curve?

• it starts out at ~1N-m, then follows a gentle contour..

• until 2.5 rads, where it takes a straight diagonal line down to zero.. right around 3.14 rads

• it then stays at zero even as the other numbers keep rising..

..da'fuck? Since Pi seems to feature, i suspect the 'spool' code's dodgy... which i got off you, Fletch... i've literally just cut'n'pasted it here, after checking the original sim was using the same units as me (it was / is)..

I'm sure i've cleaned up this code before so will have to have a play around - if anyone else has any ideas, go for it (as in, it's 04:30 here and i'm about to go get my few hours kip before going back to work till 10 pm tomorrow)..

Meantime.. should the torque be something, or nothing? All of the gain, some, or none of it? I reckon the torque profile should look similar if not identical whether the motor speed is zero or anything greater.. that its static MoI is the only load on the weight / GPE, which for its part should be oblivious to the KE rise of the wheel..

This is an easy one to dive into - could replace the 'reel' with some other kind of angular-linear transmission, or just another motor metered up..

..gonna be offline for a good 18 hours now... anyone could knock up their own variations in that time.. either way i'll keep at it when i get home tonight..

[MrVibrating]

Naah .. he's simply saying use as many practical cross-check methods in the sim as you can. If it can be done one way, try another comparable way e.g. his springs suggestion (even if you don't agree it's comparable).

You already tried the actuator and motor options.

If the results are consistent across the board then maybe there's something to it. If not then maybe the programing is awry. Not accounting for something or over-accounting ? Doesn't appear to be top-down COE dependent software from your results.

ATEOTD to prove the hypothesis a practical physical build will be required. I know it's too early to go there but it shouldn't stop any of us from thinking about what physical devices we could employ in the sim and real world test of the sim. Then each could be tweaked against the other for that comparison and educational purposes.

JMO's.

Well, yeah.. for a build-candidate we'd want something simple and seemingly 'robust' in theory and simulation...

..i'm thinking two identical MoI's, one of them weighted, interconnected by a stepper motor or similar - something that can accelerate and brake - with a suitable controller.. as noted already, the motor and brake masses contribute their own MoI, which can be shaved off the main rotors to tune it to a target value, so they wouldn't 'pollute' the purity of the simmed interaction, as it were.. That rig's ready to build as far as i can see; should be comfortably OU.

But things are moving fast, at least when i can get anything done, and this second variation is even simpler to build, if the maths and sim results prove consistent.. you wouldn't even need a motor controller.. or a motor, for that matter..

[Fletcher]

Have a gander at Section 9 Advanced Scripting - it's the pulley system you mention. Also in there is the metering of such.

As you know you don't need to actually build a script. Just plug in the formula's where appropriate on your sim.

[MrVibrating]

OK, just tried re-running that last result at 1 integration step / frame - the previous one was at 100 i-s/f - and got this result:



..gain's down to a millijoule, and with it, any hope it was realistic..

Rerunning the penduwheel sim at 1 i-s/f now to see how it effects the results..

[MrVibrating]

@Fletch - thanks mate, didn't realise that's where it was from - i have the tutorials but have never worked through them, will use it for reference next time tho..

[MrVibrating]

Right! Bit of a nail-biting moment there, but the primary hypothesis not only survives the revision, but feckin' thrives on it:



freq = 32765 / 0.6177
i-s/f = 1
motor T*a = 0.26076304 J (!)
KE rise = 0.4749
Dissipated = 0.25 J
Total out = 0.7249

0.7249 / 0.26076304 = 2.78x unity


It would thus appear that higher i-s/f values aren't necessarily a Good Thing when pulling torque data... if so, and this is a more accurate revision, then the primary hypothesis is as close to confirmed as the sim is able to determine..

The secondary hypothesis never seemed right in the first place, since any positive torques applied to the motor would transfer counter-forces directly to the weight, thus any gain would logically be equal to the GPE output..

..hence the 'coasting whilst gravitating' phase of the cycle is functionally inert - only there as a consequence of ensuring the TRS is reached before running out of G-time due to rising RPM.

I'm sitting here waiting for work - logged in on the app, soon it'll start pinging and i'll have to ride off into the rain going in circles for 12 hours.. but if i had the day off, i'd spend it browsing RS components or eBay for cheap build options..

Is there a simple type of stepper motor or rotary solenoid that can lock its angle and basically combine the 'motor' and 'brake' functions? Or maybe just a linear solenoid for a brake - shoot a little bolt out, locking the parts with an impact; keep the TRS to 1 rad/s and the input energy to KE efficiency alone is still 0.4749 / 0.26076304 = 1.82x OU.. control it with a laptop / netbook / Arduino / Pi or whatever..

[ME]

The sim has no clue what the T*a integral even is - it has to be calculated outside the sim, in a spreadsheet.

I'm not disagreeing with that.

Could you please show that resulting graph (first cycle going from 9:00 till 6:00) so we all know what we are looking at?

[ME]

...oh forget it, here's mine.


Almost my last attempt:

Again, the motor workload is already correlated with the respective angular accelerations of the two parts - it's the right amount, no more or less. The KE gain is already correlated with the difference between the KE the bob thus loses, and the KE the wheel gains - the latter gains more than the former loses, because of the effective N3 break (gravity skews the momentum distributions caused by the applied torque), and the fact that KE squares with velocity. There is no anomaly. Nothing that doesn't match up perfectly.

Yeah well, in that case I'm just extremely slow (or running backwards) to understand how it comes that when the wheel has zero acceleration, the wheel still experiences a constant acceleration... accounted or not.

I attached some relevant frames of your GM4-HQ .gif so we don't have to hunt for the values.

At t=0.2007 s, the motor stopped accelerating after a measured 18.9°.
So we can conclude that your T*a integral should show about 26 Joules at that timestamp.

When the frame of reference of the bob would have been inertial, then there would indeed be no need to add more torque. (Newton-1st)
Yet, the entire frame of reference of the bob is non-inertial because it's accelerating due to gravity acting on the bob.
And, to paint the image for co-readers, we can all experience that backpressure inside an accelerating vehicle that's caused by inertia.
In that frame it certainly needs a force for the remaining sector till BDC to counter that fictitious force in order to keep its relative velocity at 10 rad/s,
!!-- as like rolling a ball forwards when the train is leaving the station, it not only has to counter the effect of relative deceleration, and possibly rolling relatively backwards, it also has to increase the speed relative to the station so it is always going 10m/s faster than the train... --!!

Thus I conclude that on top of that 26 Joules the motor has to invest additional work, as there's nothing else coupling it to the bob.


MrV. I understand that you don't agree with that conclusion, but I would still like to know how you think that motor keeps its 10rad/s difference for the remaining 70°.

Because I'm on the other side of the fence, an N3-break is not a reason but a revolutionary conclusion.
And I really don't know what this should explain without specifics: "gravity skews the momentum distributions caused by the applied torque".

[MrVibrating]

But this I dare to claim - if God allowed me a long enough life I could make my wheel go really slowly, with a gentle rhythm, and it would still be able to raise even greater weights!

So to recap, higher TRS values are increasingly more efficient, however an ever-increasing proportion of those ever-increasing gains is being produced as heat, and the ratio of input PE to output KE actually goes negative.

Hence, if KE is the desired form of output energy, it would seem to make sense to go for even lower TRS values than 1 rad/s... because, why stop there? Just an arbitrary round number..

..why not try ½ rad/s, or ¼ etc.; each halving of the TRS reduces the input T*a by a factor of 4 (because of the V² multiplier); to raise the energy density with such small displacements, increase the amounts of mass / MoI.

For instance maybe give each part an MoI of 10 kg-m², with 10 kg of weight and a TRS of 0.1 rad/s... how efficient would that be?

Might try it after din dins..

[MrVibrating]

@Marchello - suppose instead that the brake activates the instant the TRS is attained; The results will be pretty much identical.

Similarly, suppose the timing is accurately controlled such that the torque is evenly distributed over the full 90° arc; again, the energy result would be the same.

The corrected 'spooling motor + rotor' sim from this morning shows that the motor applies torques to maintain the TRS relative to the gravitational acceleration of the net system.

I posted a similarly corrected single cycle of the 'GM4' interaction with the spreadsheet and screenshot, so you can see the plot, the numbers that generate it, and also re-run the sim that produced them.

Again, the coasting-while-gravitating phase is functionally inert - a zero sum game. As i originally expected it had to be, since it's a) not internally consistent, and b) entirely redundant; we already have the gain principle wrapped.


And also in repeat of what i've already explained, it should not be possible for torques to escape metering; this can happen due to 'temporal aliasing' effects (ie. insufficient frequency), in which case 'zooming in' in time will iron out the problem, reducing the anomaly. In this case however, we can spread a single cycle over all available memory and the gain margin is refined - we shave more zeros off the coarser 10-cycle result - not eliminated! So no, i do not see how any unmetered torques could be arising.

Furthermore, they'd be redundant anyway, since the T*a profile is fully consistent with CoE - again, accelerating 1 kg-m² to 1 rad/s would cost ½ J, but applying a relative 1 rad/s acceleration between a pair of 1 kg-m² inertias only needs accelerate each to ½ rad/s, and since KE=½Iw², each acceleration costs one quarter as much, and since there's a pair of 'em, ultimately half as much, ie. ¼ J. That's how much the T*a plot integrates in the 'no grav' baseline (everything else left the same, just gravity turned off).

In this morning's i-s/f=1 revision, we're seeing a T*a sum of 0.26 J. This is because the bob was decelerated slightly less than ½ rad/s, and the wheel, slightly more; KE squares with velocity hence the reduced work done on the bob caused a smaller drop in its T*a cost than the increased cost of accelerating the rotor slightly faster, hence the two changes, increase vs decease, are asymmetric with respect to each other, resulting in a net increase in energy cost for the 1 rad/s relative acceleration.

You've got to remember tho that the whole point of 'inelastic collisions' is to reset the speed difference, such that each successive cycle begins with the two parts stationary relative to each other, in order to start at the very bottom of the V² multiplier each cycle; implicitly a key requirement for OU (ie. discounted momentum). Hence 0.25 J is the right amount of work done for a perfectly symmetric inertial interaction. Ours is slightly skewed by gravity however, so it cost a little more..

..but the payoff of riding an accelerated reference frame is geometric - again thanks to the V² multiplier on the KE value of that gravitationally-accelerated FoR.

That last single-cycle revision gets a total excess of 0.725 J (KE plus dissipated losses); if we're to attribute all of this to motor T*a - just completely abrogating any attempt at actually taking a measurement, and simply 'guessing' that all of the gain presumably came from unmetered torque - then the challenge there is to show just what that 0.725 J of work was, exactly? Because we only achieved a 1 rad/s relative acceleration between two 1 kg-m² inertias that were stationary relative to one another... so 0.25 J would be our ballpark reference value, and in reductio ad absurdum, if the inertial interaction had instead been fully asymmetric - that is, all of the acceleration applied to one part only - then a 1 rad/s acceleration of 1 kg-m² costs 0.5 J.. not 0.725 J!

So, what might cost 0.225 J more energy than a fully-asymmetric interaction, even tho it wasn't one? Where did that energy go, Marchello old boy? What work did it accomplish? You only want it to be there to curve-fit a preferred negative result, but there's simply no load there that could substantiate it. For the relative accelerations that actually happen, the input integral of 0.26 J must be right. And the amount that gets dissipated is only 0.25 J per cycle - again, it's the same numbers involved; the T*a integrals are reliable, there is no anomaly, and no new physics. It is simply gravitational acceleration of an inertial frame.. 'transposing' our plain-old mechanical energy, right up the V² multiplier, whilst towing the planet with the bob, via gravity. Basically, causing the planet to fall into its own gravity well. That's what substantiates the momentum gain. The energy gain is coming from the Higgs / Mach's principle / whatever gives mass or inertia its properties. The ZPE. (wooo!)

There's a succinct maxim quite pertinent here; it is impossible to explain away a genuine classical symmetry break, without invoking (usually quite blithely) some other symmetry break up or downstream that will cancel it out.

This is a logic trap that pathoskeptics pour into with a herd mentality..

What corporeal, manifest 'work' could 0.725 J have accomplished besides ~0.26 J of ~½ rad/s accelerations of a pair of 1 kg-m² inertias that were static WRT each other? Your hoped-for 'out' is just another corner, sir.. a cul de sac.

Everything in that last sim was as fully consistent with all laws of physics as it is capable of being. CoM and CoE are being respected at every step! The gain conditions are fully dependent upon all conservation laws holding just as they're supposed to. It works because of CoE and CoM, not in spite of them. Counter-momentum is being induced to Earth, from gravity * time. 'Buy a gravity wheel, get a free warp drive!'*






﹡ʷʰᵉᵗʰᵉʳ ʸᵒᵘ ˡⁱᵏᵉ ⁱᵗ ᵒʳ ⁿᵒᵗ

[MrVibrating]

Okay here's the clincher:

• 0.25 J is the minimum cost possible of a 1 rad/s relative acceleration between two 1 kg-m² MoI's. It can't cost any less than this.

• Any increase above this cost implies that an asymmetric inertial interaction has transpired, since the MoI's are equal; the T*a work integral can only be > 0.25 J if the accelerations were unequal!

IOW, an effective N3 symmetry break has occurred..

• Thus the greater the T*a integral - towards its maximum-possible value of ½ J - the greater the corresponding KE gain.

Quite unassailable, i think you'll find...

In short, the OU efficiency is a function of how far the T*a integral is offset towards its max-possible value of 0.5 J, from its min-possible (and default) value of 0.25 J.. if the resulting velocity distributions are asymmetric then it costs a little more to spin up, but pays out much more on the spin-down.. since the spin-up T*a is relative to the free-fall FoR but the resulting KE is relative to the ground..

There is, however, no physical way to spend 0.725 J on a 1 rad/s relative acceleration between two 1 kg-m² inertias, one of which is also a 1 kg weight - the most you can spend there is 0.5 J. The interaction simply cannot cost more. These phantasm unmetered torques, somehow slipping thru a 50 kHz sim, have no work to do, no mass to displace, no purpose at all but to retrospectively back-fill an otherwise inexplicable (for Marchello) PE to KE asymmetry..

..by invoking an under-unity inertial interaction...!

Logic, bitches.. ;)

[MrVibrating]

Couple more quick results this morning:

..MoI of 10 kg-m², with 10 kg of weight and a TRS of 0.1 rad/s... how efficient would that be?

dissipated = 1158.2865 - 1158.2680 = 0.0185 J

T*a = 0.142971195 J

KE rise = 0.388 J

0.388 / 0.142971195 = 2.71x unity for KE alone - (negligible heat anyway)


..and with TRS raised to ½ rad/s:

T*a = 1.11450811 J

KE rise = 963.4741 - 961.7038 = 1.7703 J

1.7703 / 1.11450811 = 1.59x unity (again, ignoring losses)


So this confirms the observation that lower spin-up speeds offer optimal PE to KE efficiency, minimising the proportion of 'gain' that is otherwise dissipated as losses.

However if maximal power density is the objective, then we want the internal accelerations to be as high as tolerable - 10 rad/s or more, bring it on - and thus either a thermal plant in the loop (crazy), or else some way of harnessing the gain and re-equalising the speeds without using dissipative braking..

If instead the 'braking' was accomplished by radially re-lifting the weight - per classic OB - this would introduce much more G-time asymmetry and thus momentum gain per cycle.

Remember the 'changing GPE without changing MoI' trick from earlier? What if that were to replace the current pendulum?

Then we could adjust the weight / GPE independently of the MoI, too..