Blood From Stone

[Fletcher]

Go for it cobber. If it's to good to be true it probably is, comes to mind, but I'm a natural skeptic unless I checked something a hundred times a hundred different ways.

I'll try and find an old sim I built years ago where I had basically a pendulum with parallel wings attached that fell under gravity and produced Lift and Drag forces from the wings. These Lift and Drag forces were generated in Output boxes and fed into a side view of the aerodynamic wheel pendulum because when they built up they snapped the wings together and thru a "pull mech" and stator pulled the wheel pendulum forward increasing its speed even further (positive feedback). You could see the L & D forces building etc as wing speeds increased etc.

These disembodied L & D forces were then 'cloned' into the face view of the wheel pendulum where the dual wings could not be shown to close or open i.e. they were linked to the control forces.

You can watch the sim in action and see the forces developing and being transferred elsewhere. Look into the properties and follow things around to get a feel for it if you want. Maybe you can find a use for a similar application in your approach.

If I find it tonight I'll edit this post with the attachment. Ok got it. Wings start just off upright and fall CCW.

[ME]

Looks cool Fletch!!
There’s definitely a use for mrV’s setup. Duplicate it 180 degrees, and put a larger weight at 90 degrees.


To indulge mrV’s evading whataboutism...

Marcello will lead you astray

To Fletcher (/s).

According to mrVibrating, you are just following me!
I had no idea.... why Fletcher! Why are you following me?!
And I wonder, how can it this be my fault?

I'm not sure where I actually should lead you to, besides astray... perhaps you could give me some pointers on a destination, and then I'll see what I can do. I hope you don't get too lost in the mean time!
In case your choice of POI is "a working perpetual motion machine design based on real principles", then I have to inform you that I'm still tinkering with some possibilities... takes just one or more moments - please hold.
Sorry for all my astraying I may have attempted.
:-)
Despite all my "influence", an excellent tip: http://www.besslerwheel.com/forum/viewt ... 341#163341
(Maybe you astrayed me first? Is "astray-demic" a valid word?)
I read that post as a hint: Check the actuator in a stand-alone environment.
It just emphasizing that exact Scientific-Method mrV bragged about for already using, yet fails miserably to proof he really does. (Ironically).

- - -

At least there is something to agree with, and that's with mrVibrating's intended (I'm never really sure with this guy) statement: "Calculate the Energy by Force over distance".
I just keep disagreeing with his implementation and conclusions.
Work-done by the actuators against centrifugal should reflect the gain in kinetic energy... easy-peasy, but no OU.

Sure, Marchello may not understand what V's babbling about... How could he, when mrV doesn't either in his own topic?

A marvelously and extremely funny and stunning demonstration how mrV totally trolls himself.
Mistakes may happen to all of us, and it's therefore often most interesting to discover how that may have happened.
But Yo V-dude! How was that "F*d" made [link] "suspect" again?
Why was it suspect, please tell? How did he know? We want to know!!
Simple, as 'reported': It just did not fit-in with those other numbers.
I think that makes total sense because shouldn't we all be familiar with that arbitrary unwritten majority rule, and thus blame that unfortunate outlier?
Still strange that the other values where considered "correct", yet overunity was assumed and held strong... in a simulator, which is unable (as explained).
No matter the cause, it truly has an immediate effect on all those earlier attached hip-hip-hooray-conclusions, which were totally based on that same nonsense, and now get thrown away just as easily.....and nevertheless still continues, because "F*d" rules bigtime?
This "F*d" is just weird anyway: it only makes sense when acceleration remains constant because such simply removes the integral sign (∫F dd) as a simplified solution. This constancy is not the case when moving radially through a centrifugal field while also rotation varies. And integrating a current force times the current radial distance makes zero-sense in any situation.
Even the correction is flawed.
Because as always, the units got 'wisely' guesstimated. Ehm no Mr.: Integrating (F*d over time) does NOT "equate with the dimensions of power".
Power is in units [J/s]. And with simpe dimensional analysis you'll find that the integral [F*d over time] has units [J·s].
(How typically not-so-'rad' that circular reasoning gets confused with power)

It all seems very deliberate, or (..)
If not, then he should just just build it. He is one of the very few who is so convinced. How much more OU does he want the same design to get?

From: http://www.besslerwheel.com/forum/viewt ... 441#163441
Discussion: The two most striking results - the 580 J gain, and the 394 J loss,
This 580 should have been calculated to be closer to 370.... .
When we ignore the initial actuator spike (after 3 or 4 timesteps) then it should actually be calculated to be closer to 1280.
Seems a lot of sway (and simulation depended) to base any conclusion on.

And why might there be a spike on start-up?
Because the actuator accelerates the center weight from the center from 0 to 71 m/s almost immediately. In the mean time, the green weight (with some initial speed) pushes the weightless wheel, which now accelerates from 0 to 341.646 rpm in a timestep defined by the frequency of the simulator. This causes the red center weights (now no longer in the exact center) to be accelerated into some rotational path....and the actuator suddenly experiences a centrifugal.

Even though the method should theoretically be more-or-less sound, the execution is far from it... again.
Thus, those values are very unreliable... again.
And with that goes any attached conclusion and basically all grandeur out the window.. Again.

Breaking down the 580 J gain into its component parts and carefully retracing their development seems like a good first step. The answers must be right there in the data..

Yes, it's broken all-right.
Let's time how long it takes to "realize" this current mess-up, and get replaced by new pretence.

"Yet, the pictures are nice though."
LoL

[cloud camper]

With Mr V's actuators retracting the weights to center at maximum rpm in the cycle and extending the weights at minimum, this is analagous to lifting a weight in a non rotating environment when gravity is set to 2G then dropping the weight after adjusting gravity back to 1G.

We then do twice as much work lifting the weight as we recover when dropping as given by GPE = Work = mass x gravity x height. If gravity is doubled for the lift it takes twice as much work to lift as we get back when the weight is dropped at 1G.

But V keeps telling us that the actuators are not being fed energy and argues for a zero sum game.

This is clearly wrong per physics and must certainly be the the source of error. The actuators are clearly doing more work on the in stroke than is recovered on the outstroke which then causes the wheel to accelerate each cycle as more and more external energy is added to the system.

Case closed for me!

But great effort Mr V! Next time could be the one!

[Fletcher]

Thanx ME .. it was the only sim I ever built that actually showed OU, legitimately. That is I used Industry Physics formula's for Lift and Drag forces according to different wing profiles on line. I had realised when I mapped the energy consumption of Lift and Drag that there was more than sufficient Lift to overcome system losses including air Drag and it got better and better with some profiles which had to translate to speed/velocity over tdc (which the sim does). What could possibly go wrong ?

The build didn't measure up at all. Failed to perform in the circular environment anything like the sim predicted. Always UU. Then I realised that when they said the Lift and Drag Physics formula's were best approximations for the 5 theories of flight, pretty good predictive abilities in wind tunnels, they just did not reflect the real world accurately enough to be of use to me.

...........

Anyways, I think all of us sim users should pitch in and see if we can get to the bottom of Mr V's sim actions. Maybe we can collectively come up with a mech substitute that can make the shifts something like his sim and we can plot the energy consumption against what is available (if we can agree on how to, and what those figures are) to see if it physically can be done.

I have to make two posts coz I have some pics to load up - more than 4.

First I rebuilt the sim with Red Radial Wts moved by Actuator Length, and beside it with Rod Length controlled. They both behaved exactly the same.

Note I gave the background wheel a 1 gram mass as any Body in a sim with zero or negative mass can cause the sim to throw a leg out of bed, catastrophically sometimes.

I left in the initial push parameters as an Input as per Mr V's wishes. N.B. well over OU with no push start.

Anyways, take a look at the pics (hopefully self-explanatory notes) and the sim. I dropped out things and included other things I think are telling. See what y'all think.

Back next post to discuss some observations of the sim.

[Fletcher]

more ..

[Fletcher]

more .. First Cycle Only.

OK .. follow the pics and read the Outputs, or run the sim and stop it at critical points before continuing etc.

Basically the Actuators or Rods do the exact same job, and their length and thus radial position is controlled by formula.

But take a look at the rpms and the Total KE's. As an example at MZ System KE goes from GPE 19.6 to a wopping KE translational of 130.9 J before centering and immediately dropping down to a mere 66.0 J's.

Also after 12 o'cl tdc where the system has 26.3 J's (Gain of 6.7 J's) it instantly jumps up to 54 J's.

This has got to be because of the manipulated Red Radial Wts transitioning. In part that the Raod or Actuator gains half its length again at 30 degrees down and loses half its length at 30 degrees up - IOW's rapid Centering while going fast. That means big Cf's in play.

So somebody has to come up with a reliable way to analyse this energy cost ?

At the minute it looks like erratic energy jumps in the sim which just shouldn't be there IINM.


Cheese Burger time !

[MrVibrating]

MSD_3i2 breakdown:


Original results:
___________________
Freq: 171913.53166483026391730940762894 Hz
Initial RPM: 382
Initial RKE: 3.2 kJ
Act. P*t = -628.413 J !!!
CF P*t = 23.49332 J
KE rise = 23.71404 J
___________________




***************
Slo-Mo re-take:
***************

Each section of the integrals above and below the zero line is now retaken at max possible frequency.



First 90°, from 12 o' clock TDC to 9 o' clock:

Freq: 557341.63434714567598829693134653 Hz

Period: 0.058788 secs

Initial KE: 3200 J

Final KE: 1616.380893 J

CF/CP F*V: -1603.273075 J

Act. F*V: -1962.290235 J




Second 90°, from 9 o' clock down to 6 o' clock BDC:

Freq: 608992.23077209025686777443217724 Hz

Period: 0.053802 s

Initial KE: 1616.380893 J

Final KE: 3262.943943 J

CF/CP F*V: 1626.924479 J

Act. F*V: 1625.617084 J; of which:

• @ 879880.76695848326977818357591707 Hz
• Period: 0.037238 s
• 2694.682301 J is above the zero line, and:

• @ 1978323.8739282695326651370607415 Hz
• Period: 0.016562 s
• -1068.940208 J is below it.




Now stitching it all back together:

First 90°:

KE drop: 3200 - 1616.380893 = 1583.619107 J

CF/CP F*V: -1603.273075 J

So if the CF PE came entirely from the RKE:

3200 - 1603.273075 = 1596.726925 J of KE would be left

But we have 1616.380893 J left, so:

1616.380893 - 1596.726925 = 19.653968 must be our GPE:

9.80665 * 1 kg * 2 meters = 19.6133 is the exact GMH for 2 meters, and the pause point in the sim is unlikely to be exactly at 2 m, so the CF work and RKE are consistent.

That all looks OK. Now for the troublesome actuator F*v integral:

Act. F*V: -1962.290235 J !

Compared to the CF integral:

1962.290235 - 1603.273075 = 359.01716 J of extra PE has been banked - an apparent 22% gain.





Second 90°:

First off, let's tie up the two CF/CP F*V integrals:

From the first half, the integral was -1603.273075 J

For the second half, it was 1626.924479 J

1626.924479 + -1603.273075 = 23.651404 J

Initial KE at TDC was 3200 J

Final KE at BDC is 3262.943943 J

This includes 9.80665 * 1 * 4 = 39.6266 J of GPE, so:

3262.943943 - 3200 - 39.6266 = 23.317343 J was the KE rise from the CF workload.


...so far so good...



Initial KE: 1616.380893 J

Final KE: 3262.943943 J

So:

3262.943943 - 1616.380893 - 19.6133 J of GPE = 1626.94975 J

..of CF work must've been done in pushing the masses back in, so in good agreement with the actual CF work integral of:

CF/CP F*V: 1626.924479 J

So now let's look at the dodgy actuator integral:

Act. F*V: 1625.617084 J, so they used:

1626.924479 - 1625.617084 = 1.307395 J

..less energy than the CF work done.


Given that we're dealing in kilojoules here, that 1.3 J 'gain' is probably at noise levels.

Adding it onto the 359.01716 J gain from the first half would just seem silly...

oh go on then; 359.01716 + 1.307395 = 360.324555 'J'.




--------


~1 Joule of magical free energy from nowhere for each and every increment of degree-to-radian rounding error, would appear to be the blunt message, apparently..

Trying to make results more 'presentable', i switched from displaying angular speed in rad/s, to RPM. Since the output of the angular speed meter is used in the angular momentum and RKE calculations, WM automatically applies a multiplier to convert between rads and degrees, like this:

"Body[1].v.r*1.047198e-001"

..where that "*1.047198e-001" isn't usually there when you're working in radians rather than degrees / RPM's.

Obviously that's a finite number, whereas Pi is irrational, so this seems a possible source of rounding error, at least on first glance.

That said, an anomaly was being measured consistently before making that switch in the most recent sim revisions, so we're not quite out of the woods yet..


The other obvious issue is that the original sim showed a gain of 628.413 J, whereas now it's apparently slashed down to a measly 360.324555 J. What's changed?

The original sim was taken at a single - very high, but fixed - frequency.

In the re-takes however, each individual section of the integral, above and below the line, has been simmed independently, at the maximum possible frequency, using all available memory.


Therefore the 'gain condition' appears to be both resistant to very high sim freqs (in that it persists), but also in some way dependent on sim frequency - otherwise these higher-definition re-takes would've further refined the 628 J figure.

Instead, it's knocked 314 J off of it. Almost half.

So, something funky's happening during the first half of the drop stroke.

So i'll turn my attentions back to that first half tomorrow.

With any luck, all should soon become clear..!

[MrVibrating]

Star turn, Fletch - had a play with your 3D flying pendu-wing, fecking ingenious, well impressed!

Fantastic that you've got a replication up and running - i'll grab some high-def data off it tomorrow, however i expect we'll see dissipative losses as the masses go from very fast to a complete halt at the center.

I've been thinking about ways to implement acceleration damping using a 'length' input - you know it's possible - just a matter of condensing the formula right down.. all my attempts so far are too long to fit in the properties field (I've found that if equations are too long, yet still seem to fit in the field, the resulting save file is corrupted and can't be reloaded - so watch out and make regular backups when trying very long functions!)

"Acceleration damping" can't be lossy - in order for the masses to decelerate neatly to a halt, and so returning all radial KE to PE, whilst still maintaining sync with the required angular quadrants, they have to accelerate all the harder initially, reaching a higher velocity mid-way in or out..

..before grabbing the anchors and screeching to a halt at the center.. non-dissipatively, and in-sync with the rotor angle. So while there's nothing mechanically intractable about it, it is an outstanding issue that may yet need resolving if there is an anomaly..

We can maybe get around squeezing the formula into a single properties field by putting it in its own meter and then simply referencing its output or whatever..

or, like i say, we could just 'write down' the dissipated losses and plough on as if they were saved, to at least see if we have an OU heater..

Coming up with some of these formulas can take me 18 hours of hair-pulling, no exaggeration.. i am so shite at maths lol..


To help check for the anomaly, we'll also want a CF/CP meter, so's we can compare that to the forces - and thus work / energy - being metered from the rods.

Obviously, sticking to radians throughout from now on would seem wise - we can knock up an RPM meter using our own conversion factor..

Given the persistence of the effect so far (into the megahertz now), i do expect your version to show the same result..

FWIW i'm using this procedure for the plot sums - i keep an "integration template" as an .xls file with the formula preset in column C, so all i need do is open WM's exported .dta file, copy and paste into the Excel template from the 'recent files' menu, scroll the column C equation down to cover all data, sum it and delete the last row from B.. and Bob's yer uncle.

Such a relief to finally be making progress tho - this has been twisting my nut proper for the last fortnight..

[MrVibrating]

..on 2nd thoughts, the 'rounding error' theory is just that, until confirmed by re-running the results with the attempted correction.

Reason i say this is because the gain was persistent before this change was made, but also...

..the CF meter is dealing in the same quantities - from the same sources (but for the forces - they're both using the same angular speed measure, the same radial velocities, and mass values, anyway) - they're both dealing in the same large magnitudes; big hefty impulses at high mechanical speeds.. and yet the CF work integral sums back to a neat 23 J, within mJ of the RKE rise.

They're both using the same energy terms, with the same units and dimensions..

IOW, the only difference between them is the provenance of the 'force' variable - one's actual - literally sensed from the actuators themselves - whilst the other's purely mathematical - just a rolling update of the calculated CF. And "force of actuator" is nothing to do with angular units...

So the "360" value could be coincidental, and completely unrelated to the rad/s / RPM conversion factor.

The frequency-dependence however seems more certain. Yet the anomaly still stands at 360 J, even at higher frequency.

So, logically, it'll either keep changing as a function of ever-rising frequency (and there is no practical limit to sim frequency, besides run-time of course) - in which case it was probably only ever a glitch - or else it'll stabilise towards some value, in which case we might yet have something...

So the game remains very much afoot, for now..!

[WaltzCee]

But if OU cannot be formulated then it cannot exist.
What is OU, but excess mechanical energy? Thus if it can exist,
it can only be derived using the standard energy terms.

I'm sure a working wheel could be analyzed using 'the standard energy
terms'. However I doubt seriously a working wheel can be based on
some exploit of these terms, which I think you are tying to do.

I had a wheel in simulation spinning at 9.2 milliion rpm, it started by
itself. No motor, actuator, etc. The CF calculated by wm2d didn't
cause the parts to be pinned to the wall. They still moved. I think
I blew the sim's mind.

Keep trucking. Never know what can come from any civil discussion.
Lot of folk enjoy reading your walls of words. :)

ETA: You probably know you can mash 2 graphs in wm2d together,
using the formula that produces one and multiply it (add, subtract, etc)
with the formula of another. Cool feature.

[ovyyus]

But if OU cannot be formulated then it cannot exist.
What is OU, but excess mechanical energy? Thus if it can exist,
it can only be derived using the standard energy terms.

That seems like narrow thinking. Fletcher has already pointed out some of the difficulties in formulating the physics of airfoils, yet flight obviously exists. Furthermore, flight exists without the need to re-write any fundamental laws of physics. Perhaps Bessler found a similarly difficult to formulate phenomenon to lift his weights, deeply hidden in nature and beyond the narrow thinking of splendid mechanics?

[MrVibrating]

But if OU cannot be formulated then it cannot exist.
What is OU, but excess mechanical energy? Thus if it can exist,
it can only be derived using the standard energy terms.

I'm sure a working wheel could be analyzed using 'the standard energy
terms'. However I doubt seriously a working wheel can be based on
some exploit of these terms, which I think you are tying to do.

A perfectly ordinary mass acceleration, sans counter-momentum, is over-unity.

It get's ridiculously more OU, the more you do it.

"KE" is "½mV²".

Regular KE, excess KE - KE is KE.

Motion is relative. Velocity, is relative. Thus KE is relative..

..to a given non-inertial (ie. notionally static, or at rest) reference frame.

If that frame is however subject to a rise in momentum sans counter-momentum, then it effectively becomes an inertial (ie. accelerating) frame.. albeit, one that breaks energy symmetry with all other reference frames.


So this is essentially what terms like "excess KE" and "mechanical OU" are describing - it's their literal interpretation.

Still, nobody in their right mind should believe such a thing is possible.. but for the evidence of Bessler's witnesses, not least the world's most qualified magistrates of such claims, the very men who invented CoE, Gottfried Leibniz and Willem 's Gravesande et al..

Given their testimonies, it becomes all but apparent that an gravity-assisted effective N3 violation is indeed possible..

..and there is nowhere for it to hide. It has to - can only, exclusively - fall out of a combined gravity / inertial interaction. Inelastic collisions could help consolidate the net momentum rise.


So with very basic physics, it's completely trivial to plot out a gain in KE. Just using the standard KE terms, standard momentum terms etc. - no new physics required, or possible at these scales.

To believe a solution is possible otherwise is to believe in magic..

[MrVibrating]

OK, tried reverting back to rad/s instead of RPM. This raised the gain, to almost a kilojoule..

So i tried setting Fletch's version to the same initial conditions - 40 rad/s initial speed, which equates to an 'edge speed' for a 2 meter radius wheel of -80 m/s, for the weight.

The measurement of interest is the radial work done during the first 90° of the cycle, a persistent excess being the problem.

However it appears that using rods instead, things only get worse: setting those initial speeds, and maxing out the frequency for the drop period (32765 frames / 0.058788 secs = 55743.645581680220490659770662493 Hz), the integral comes in at over a megajoule..!

It's a negative megajoule, not postive, so the gainy kind, not the lossy kind. The good kind.

Obviously not worth Monopoly money tho..

Given that the RKE is only 3.2 kJ, and that it goes to 1.6 kJ at 90°, and also that the CF profile's already been measured in the other rig for the same conditions at ~ 1.5 kJ, it seems safe to assume this should be our true output energy..

The PE netted here should be equal to the drop in RKE, plus the drop in GPE. At most.

You gotta ask, what does the sim 'know' about? It knows about inertia and gravity and force, mass, distance etc. etc.. ie. just the fundamentals. It can't invoke new fields or forces etc. - no new physics - so this has to have run its course i think..

Looking at the F*V plot for the rods, it's a real bed of nails - as if they're still being treated as 'rigid' every other frame or so - the spacing between the spikes increases as the masses move outwards, increasing the negative torque and slowing the rotation, and thus the radial speed, hence the rods are receiving less frequent 'length' updates, and so experiencing bigger jumps in length, maybe.. dunno, but a smooth output curve seems like it's gonna be more difficult using this method, and any attempt at using 'accel. damping' tricks could end up only worsening the issue..

The initial reason for accel damping was unintended dissipative losses as the masses slammed back into the center at speed. This only began to happen at higher speeds, tho - after excess energy was already being measured. I wanted to eliminate those losses to see how high the gains might go with speed..


..like i say tho, the formula for it gets loong, so i only applied it to the problematic inbound stroke - doing the outbound stroke too seemed unnecessary, given the extra time that would be required to condense it down into something that would fit into the input field..

So while this eliminated the unwanted losses, it would now seem pretty obvious that this omission has been allowing the inverse effect, of unwanted gains, to slip in..

Given the amounts of energy likely being both created and destroyed when using the 'semi-rigid' rods method, the megajoule gain is probably perfectly accurate.. within its own terms of reference..

But pulling the process apart and putting it back together has at least helped clear up any vague notions or grey areas i may have had about what was or could be happening - there's RKE, CF work, and gravity. That's it. No other core physics in play. It's thus gotta be a zero sum. There is no grey area - no room for some hidden or missed anomaly.

Conversely, there's always room for error, at any level of a measurement..


Furthermore, the actual goal being pursued is to break N3 by buying momentum at an energy cost that doesn't square with velocity.

Very specific gain conditions, there.

So we've achieved a constant input energy per-cycle - the input / output CF work per cycle is always the same, invariant of RPM.

That seems a cool trick.

And we can gain momentum - from gravity - in a closed system of mutually-rotating masses, without applying conventional torque or thus counter-torque / counter-momentum.

Also a cool trick.

But it's equally obvious that our per-cycle momentum yield can only decrease with rising velocity...

..yet we also know that the per-cycle input energy is fixed, whatever the velocity...

..therefore we know that as-is, the input energy cost of momentum is effectively increasing in direct proportion to velocity.

Each cycle does 23 J of work, and causes a 23 J rise in net RKE.


However, if we were seeing an effective N3 break, input energy would still be 23 J per cycle, but output RKE would be rising each cycle - so we might see a 23 J RKE rise on the first cycle, but then more on the second and even more on the third etc. - whilst the input energy remained at 23 J p/c.

Now that would be really cool...

..but we're evidently not there yet..

..and pissing around with this nonsense isn't gonna get us there any quicker.


So i think it's time to take whatever's useful from this, leave what's not, and form a new plan of attack - re-assessing objectives, priorities, and best use of limited grey matter..

Obviously we have to check out these false positives, but in this case i think we've pretty much reduced it to a single most-likely possibility - at higher accelerations, the sim is losing track of F*d - whichever component is bugging out, it's due to an effective zero-time acceleration; the radial masses go from stationary to having 3.2 kJ in just a few frames, even when simming at ludicrous freqs.

FWIW i did try pre-loading the radial masses with their outbound KE instead - the intention being to alleviate that load from the actuators, eliminating what i suspect to be the problematic initial radial acceleration, however this had no effect on the results.

Still, it has to be error. It's flitting and morphing with changing accuracy settings, and seems to have no definite form we can home in on, doesn't converge to or match with some other particular quantity, besides - coincidence or not - coming in almost square at "360" when converting to RPM from Pi radians..

It's all alarm bells and inconsistencies, isn't it..? This ain't the stuff of 'success'..

The only circumstance in which it could be real would be if the PE loaded during the first 90° was then subjected to an effective N3 violation and converted back into KE without producing counter-momentum. Then we would expect to see KE gains (not PE!), and in direct, easily-calculable proportion to the 'reactionless' momentum rise.

Such an interaction would certainly constitute one possible variation on our ultimate goal.. but this aint it, and we ain't there yet..

My whole ethos - the thing that drives me, here - is that the solution has to be consistent with known physics. In other words it has to be piss-simple straightforward A + B = C. KE gains from an effective N3 break are the only peg that fits that hole. But when we see it, it'll instantly be perfectly clear what's happening and why - nothing mysterious will be happening, besides the momentum asymmetry. A 'gainful' acceleration, producing excess KE, is exactly the same as a normal one in every detail, except for the shortfall of counter-momentum.

Time to get back on-track..


Here be dragons..

[MrVibrating]

ETA: You probably know you can mash 2 graphs in wm2d together,
using the formula that produces one and multiply it (add, subtract, etc)
with the formula of another. Cool feature.

Yes, it can save a lot of time and space to simply reference another meter already using a formula than write it out again, and similarly, you can build up complex variables like instantaneous RKE as a function of varying radius and velocity etc.

It's essentially like programming, except using meters and inputs / outputs as variables.

What i really want to be able to do is make up a system of meters that perform a Riemann integration in real-time and present the rolling total like any other meter. WM is solving real finite-range integrals under the hood (that's how it works), so it's a shame it doesn't provide user-access to that kind of functionality - retrospective results from a spreadsheet are better than nothing, but time-consuming.. But it's not a current priority, time-wise..

[Fletcher]

Energy is the currency to do Work ! Input and Output.

The sim will auto-calculate the correct MOI for componentry. MOI is found by experimentation in the real world.

Here is the Energy vs Rotational Degrees Mapping of the Rod sim n.b. the sim gets a small push start or 0.25 J

Note the sudden spikes and dips in the KE's and when (as in degrees) they occur.