Blood From Stone

[MrVibrating]

Hi Mr V .. spent a few hours today looking behind the scenes of your sim. Not trying to shade you. Just some thoughts on fundamentals.

The Actuators displacement is controlled by Length of Actuator formula (for those that can't see this) which is dependent on 2 relative points in the wheel. So independent of any capacity to do Work formula.

I dumped a lot of the MOI stuff and went back to basics of Green Driver GPE/KEt and Red Loads KE translational vs System KE to see how things lined up.

I note that the extra energy you apparently see comes from that Actuator length formula controlling the position of the Red Loads moving radially out and then in. And that it appears to close at first glance more quickly than it opens. This means it requires more Power to close quickly like that. And at the same time fighting against Cp's (tangential inertia). I think there must be a question mark about this.

ATEOTD since the Red Loads move equal distances radially their Net GPE remains zeroed. So we only have Driver GPE loss to convert to Driver and Loads Translational KE (KEt). Since the Driver always has some residual velocity (KE) then we don't have the full compliment of GPE loss to use doing Work on the Loads to bring them to CoR against Cp's.

This is where I think there is a problem in your Outputs. My instinct tell me that it takes more Work (or Power) to close the Loads than GPE Driver loss even if all was available to do the Work which it is not because the Driver still has velocity and KE.

It ain't easy to drive those radial loads back to CoR in an unassisted system, IMO.

ETA: Energy is said to be the capacity to do Work. It is the currency for Work. That's why I think you need to swap out the actuator length control formulas which currently dictate where the Loads are located at any time, to reflect real energy or f x d requirements an actual move would entail.

JMO's.

Mate, the actuators just control the speeds at which the masses change radius, as a function of angle.

They're not "fed with energy".

They're not "fed with energy" no matter how they're applied - using any of the default functions.

They simply supply whatever force is required as a function of the mass and acceleration.

That force is multiplied by the radial velocity at which it is applied, and then integrated over time.

And then, independently, the actual CF force acting on the masses is calculated from the standard formula, and also multiplied by radial velocity, then integrated over time.

So the energy divergence we're looking at is between the actual centrifugal force profile, and the actual energy spent in doing work against it.

Any of the actuator's input functions can be used in this way (tho "acceleration" is hardest to keep in sync to rotation) - however i thought i was returning to a 'back to basic' iteration on your advice.. the problem that does arise using the "length" control, as-is, is unintended dissipative losses as the masses accelerate hard back into the center, then slam to a halt. At lower speeds, all this KE is recovered by the actuators, however at higher speeds this begins to fail, and we get an inadvertent inelastic collision.

The fix for this is to switch to using the "velocity" control instead. The basic function used is almost identical to the "length" version, "if (body[5].v.y < 0, -point[17].v.y, 0)" - so now the radial velocity of the masses is a function of the angular velocity and angle. This sacrifices positional precision - the MoI will no longer park at the exact intended values - whilst helping to eliminate lossy decelerations.

This is further refined by adding 'acceleration damping' to the inbound stroke, accelerating harder mid-way in, then braking progressively into the center, such that all radial KE is completely recouped by the actuator integrals.

So i'm switching back to the more refined method, just to keep the data clean and consistent across the maximal range of velocity.

The energy i'm "apparently" seeing is just data, unbiased in any way - it's real data... the only question is whether the gain is real or not.

It's persistent across a wide range of velocities, with a non-linear envelope.

So whatever its provenance, it has to have an identifiable cause...

[MrVibrating]

Speed Tests
--------------


A battery run, progressively raising the 'priming' energy.


Purpose: With rising velocity, the integral of CF P*t remains largely consistent with the per-cycle KE rise. However, the integral of actuator P*t diverges. Establish how and why this is happening.


Hypothesis: The required input energy is being increasingly subsidised by CF PE harvested during the first half of each drop cycle. The evolution of the divergence seems consistent with an effective violation of Newton's 3rd and 1st laws.


Procedure: Collate results for 1 cycle, starting at progressively-higher starting energies.


Run each sim at maximum frequency, found by dividing the max no. of frames - eg. "32765" - by the precise cycle period - eg. "1.53873 s" for "sqrt(40) m/s / 20 J", so 32765 / 1.53873 = 21293.534278268442156843630786428 Hz. The period for each successive run is determined using the freq. of the current run, taken one frame before "actuator power" activates upon the return to TDC - so, while it's still reading zero.

The "starting speed" is entered into the "x vel" field of the weight's properties dialog box, as a negative - ie. leftwards, and thus counter-clockwise - value, ie. "-sqrt(40)".


Accel. damping enabled.



Results:


starting speed / KE:

-0.5 m/s / 0.125 J:

Act. P*t = 23.67469963 J

KE rise = 23.72889 J

__


-sqrt(2) m/s / 1 J:

Act. P*t = 23.54260417 J

KE rise = 23.72812 J

__


-sqrt(10) m/s / 5 J:

Act. P*t = 22.90184064 J

KE rise = 23.72709 J

__


-sqrt(20) m/s / 10 J:

Act. P*t = 22.20460357 J

KE rise = 23.72651 J

__


-sqrt(40) m/s / 20 J:

Act. P*t = 20.32202837 J

KE rise = 23.72586 J

__


-sqrt(80) m/s / 40 J:

Act. P*t = 17.89158917 J

KE rise = 23.72521 J

__


-sqrt(160) m/s / 80 J:

Act. P*t = 10.41141158 J

KE rise = 23.72460 J

__


-sqrt(320) m/s / 160 J:

Act. P*t = 2.180445685 J

KE rise = 23.72400 J

__


-sqrt(640) m/s / 320 J:

Act. P*t = -9.583162884 J

KE rise = 23.72328 J

__


-sqrt(1280) m/s / 640 J:

Act. P*t = -33.93976011 J

KE rise = 23.72215 J

__


-sqrt(2560) m/s / 1.28 kJ:

Act. P*t = -129.0786173 J

KE rise = 23.72009 J

__


-sqrt(5120) m/s / 2.56 kJ:

Act. P*t = -580.1261712 J

CF P*t = 23.5386065 J

KE rise = 23.71605 J

__


-sqrt(10240) m/s / 5.12 kJ:

Act. P*t = -608.5623264 J

KE rise = 23.70803 J

__


-sqrt(20480) m/s / 10.24 kJ:

Act. P*t = 394.2151171 J

CF P*t = 22.98956282 J

KE rise = 23.69201 J

__ __



Discussion


The two most striking results - the 580 J gain, and the 394 J loss, are pictured below:



Big gain.



Big loss.


From Johan Weise's testimonial in Das Triumphirende:

He then attached a rope to the axle – the other end being allowed to hang down out of the window. This far end was attached to a chest full of bricks - about 70 lb weight in all – and this load was raised and lowered several times by the machine. The most noteworthy detail regarding this particular experiment was that the wheel, while under this considerable load, continued to rotate at exactly the same rate as when it was running “empty�.

Emph. added.

How could a statorless motor not be accelerated when lowering a heavy load, nor decelerated when raising it?

The system must've had a preferential speed at which it achieved peak efficiency, but beyond which it rapidly becomes 'under-unity' - effectively, destroying KE in exactly the same way it is created, non-dissipatively.

We appear to be looking at precisely these characteristics in the present asymmetry. Efficiency increases towards a crescendo - currently at around 1:4.413 (a peak at around 1:5 seems a good bet?), before dramatically reducing, and then inverting sharply..

Every single run above is OU - and progressively moreso as starting velocity is increased - until the final run, where the gain inverts to a loss..



Conclusions

There's only so much you can squeeze into one weekend.. Still too early to say..

Does the possibility of error remain? It must be assumed as nothing less, until and unless a causative principle can be described concisely.

Anyone interested in brainstorming this should be getting stuck in to the above data..

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..


Files (too big to upload here).

[ME]

It ain't easy to drive those radial loads back to CoR in an unassisted system, IMO.

The thing is, opinion has nothing to do with it. You're just correct. It's basic physics.
And in this case actually already calculated by the simulator. Nevertheless interpreted into OU by ignoring the mechanism and replaced by shady formula-guessing which are coming and going depending on fitting assumptions: that's the running opinion in this topic.
On a public forum like this, others should just be made aware before hanging themselves by such wet rope.. (to make it a choice, instead of being blinded by cool pictures)

While rotation speeds up on Green's descend, then you know Centrifugal forces simply increases.
As a combined system, gravitational effects on the red-weights are balanced out against each other. Without that Green weight to give the system some MoI, it would just be theoretically impossible to reach the center while rotating,
Going towards the center not only requires more work (than it delivered when going outwards) against an increased Centrifugal acceleration, it also does it with increased speed because of that programming to keep in sync with the wheel (no matter what). Hence (to repeat) energy literally gets "FED" into the system.
I really don't understand how one is able to dismiss this when talking so much about changing Moments of Inertia...

Replace those red weights with a scissor mechanism and the actuator with a spring (or a contraption to sync it with the wheel), and you'll just end-up with a slightly more fancy pendulum than you'd have with only that Green weight.

[Fletcher]

Yeah ME .. that's exactly how I see it.

I am however trying to stay within the bounds of achievable mechanics for the Red weights shifting in testing Mr V's general OU hypothesis. He has sort of sidestepped that by having an artificial shift, formula driven (without mechanics). Then looking at the System KE and saying that once GPE losses are accounted for and the KEt of the green weight etc the balance of the energy budget must be available for the Red weights transitions.

In general terms working backwards from an ideal result.

He could do away with the 0.125 J start push by just making the background wheel at 271 degrees so it must fall under gravity alone. This would make it slightly simpler and take that out of the budget.

So he's on the right track that the energies need to be at very least calculated and compared in some way. Especially on the in-going leg vs Cf's. And as you say the faster the pendulum swings the greater the Cf's to work against in a shorter period of time to reset.

However he is not one-shot energy focused as perhaps I am. As long as there is sufficient energy available sometime after 1 cycle that is greater than the cost of Red weight shift then that is what he wants to confirm.

I still think that finding a mechanical arrangement to shift the Red weights will be critical to advancing the theory. Because Law of Levers is capacity to do Work under the Work Energy Theorem.

[MrVibrating]

..for everyone - there's no situation in WM where actuators are fed "energy", or "capacity to perform work"; the input options are force, length, velocity and acceleration. Whichever field is used, no "energy" is being input to the actuators - their "work done" is always an exclusive function of the force they've applied, integrated over some kind of spatial or temporal displacement.

This is exactly what's being metered for their input energy - the force they're exerting / or being exerted upon them, integrated over velocity times time. Integration over an oscillating displacement would produce loops and whorls, instead of a continuous line integral that we need in order to take its area and so determine the energy / work done.

The same metric of force times velocity times time is used to simultaneously calculate the work actually being done against CF force, irrespective of how much energy is being used by the actuators.

So we have consistent input and output meters on the radial work done.

Consistent, at least, at lower velocities..

So a theory on their growing discrepancy with velocity has to take account of their consistency at lower speeds.

Evidently, integration of the force acting on the actuators, over the radial velocity times time, is either near-perfectly accurate at lower speeds, or else it is perfectly accurate, and there is indeed a small gain in energy even at the lowest velocities.

Note also that the above results of the ever-burgeoning divergence are being taken at ever-higher frequency - so should be getting more accurate and certain, not less, as the starting velocity is increased.

Given that it appears to approach a peak near 1:5, whatever's happening must be eminently traceable at these magnitudes. A little more investigation should reveal the exact point at which any 'magic' is occurring.. and why.

Similarly, note well that the gain progresses to the point where input energy goes entirely negative - so we start out with an increasing subsidy.. but which then snowballs in to a generous payout, rather than a mere discount..

..it stands to reason that if this behaviour is physical, then no additional input energy will be required to operate the 'jacks' with this condition fully harnessed and under control. This likewise obviates the challenge of re-supplying them with energy from the RKE gain - they'll simply passively compress, and then decompress with gusto, all of their own accord, if the data there's to be believed..

[MrVibrating]

Yeah ME .. that's exactly how I see it.

I am however trying to stay within the bounds of achievable mechanics for the Red weights shifting in testing Mr V's general OU hypothesis. He has sort of sidestepped that by having an artificial shift, formula driven (without mechanics).

I'm sorry, i do not understand this point - the work done by an actuator or motor is the friggin' F*d of whatever mass it moves?

A real-world motor will also have friction / copper losses etc., which are omitted here for clarity of the interaction being measured.

No matter how you sequence or control the radial translation, the energy used, and work done, is the mass times displacement. Force times velocity times time is measuring this (since velocity is time rate of change of position).

There's nothing 'artificial' about controlling the radial velocity???

Your argument seems to reduce to a belief that there's something fundamentally different about using variables as inputs instead of integers, is that it? Whichever way, the force is calculated per F=MA and its inversions. It makes absolutely zero difference if you set an input integer, or a variable covering some range - the work done is ALWAYS a function of the force.

Then looking at the System KE and saying that once GPE losses are accounted for and the KEt of the green weight etc the balance of the energy budget must be available for the Red weights transitions.

Agh! NO!

I'm looking at the input energy to the actuators - so "how much energy they've been fed with", and comparing this to "how much work has actually been performed".

This is the discrepancy. Has been since it appeared two weeks ago.

There are no "GPE losses" - the weight begins and ends at the same height.

The anomaly is the difference between the energy spent by the actuators, versus the work done against CF force.

The work done against CF force is, in turn, converted to a rise in system RKE.


Note however that we have weird behaviour even there - the per-cycle workload is always 23 J... no matter how fast the system gets!

So while CF obviously increases with speed, the actual CF profile being measured, in real-time, is constant, invariant of speed.

If the system starts with 10 J, after one cycle it has risen to 33 J. If it starts with 200 J, after one cycle it has risen to 223 J, etc. etc.

So the CF force profile is not increasing with speed..

..yet all the while, the energy spent by the actuators is decreasing with speed..

Sorry, but the actual situation appears to be far more bizarre than you've currently taken stock of..

Marcello will lead you astray

[MrVibrating]

-sqrt(5120) m/s / 2.56 kJ:

Act. P*t = -580.1261712 J

CF P*t = 23.5386065 J

KE rise = 23.71605 J

If you wanna pick apart something 'nuts', there could be few better places to start..

What this data is saying is that moving the masses out during the first half of the drop would load enough energy into a spring, to send them flying back inwards, during the second half of the drop, with 580 J of KE left over after they reach the center. Divided into two ½ kg masses, that's 34.05 m/s and 290 J each.

Where the hell has this energy come from?

This energy has not been transferred to the wheel - its KE only rises by the 23 J of CF work done.

This 580 Joules is what's left after that 23 J of work has been done.

It is simply absorbed back into the actuator.

If you wanted to harness this gain - if it's real - you'd do so from here - using the actuators in a generating mode. Tapping it off would have no effect upon the RPM's or RKE, provided you didn't try taking the last 23 J of it..

None of this is 'interpretation', so much as black-and-white data..

This is a challenging problem, whatever's causing it. We're looking at a 580 J payout, from moving the masses out then back in, whilst the weight's falling..

It's not a failure to measure input energy - on the contrary, it's a massive speed-dependent discrepancy between the measured input and output energies, in an experiment designed for the singular purpose of comparing input and output energies to the actuators.

I expect Marchello to be incapable of understanding any of this, and very vociferously so - hence why he's on 'ignore'. There's no shortage of wagners like 'im, so think for yourselves..

[Fletcher]

Mr V .. I'll just have to follow along as best I can then.

Here's a screen grab of one of your actuators - notice 'Type' is Length and 'Value' is in meters, determined by your formula.

That means AFAIK that at every frame it iterates your IF statement and changes the Actuator length accordingly frame by frame. No forces, velocity, or acceleration, or any such; nor mechanics in play. Formula driven.

Nevertheless the energy budget is still the key. IOW's from the positions of the weights at various frames the system will have Angular Momentum and RKE. There is little doubt that moving the Red weights to CoR whilst swinging thru bdc increases the height the pendulum would normally swing to. IMO the difference in end GPE from Red weights locked at rim to Red weights at CoR is the energy available for the push to center. Obviously if that transition to center happens very quickly the higher will the mech swing.

ME's not leading me astray. We're simply having a side discussion about what might happen and why. If you end up proving your case convincingly then I'll be the first to my feet raising a glass to you.

[Fletcher]

If I'm correct about the Actuator set up that way then it would neatly explain the similar cost of energy each cycle, yet the rpm increases. Food for thought. Hope I'm wrong.

P.S. you could swap out the Actuator 'Piston' for a Rod element. In the Rod Length field put in your IF statement formula. It should work exactly like the Actuator using variable Lengths to determine position of the weight, IINM.

[MrVibrating]

Mr V .. I'll just have to follow along as best I can then.

Here's a screen grab of one of your actuators - notice 'Type' is Length and 'Value' is in meters, determined by your formula.

That means AFAIK that at every frame it iterates your IF statement and changes the Actuator length accordingly frame by frame. No forces, velocity, or acceleration, or any such; nor mechanics in play. Formula driven.

The formula changes the length. That moves the masses. Masses have inertia. There's also CF forces, and gravity. These forces are being directly recorded via the outputs "constraintforce(19).x" and "constraintforce(22).x" - one for each actuator.

These forces are then multiplied by the radial velocity (the rate of change of position of the actuators / masses with respect to time), and then integrated across time.

So i'm sorry but your complaint that the controls are in some sense "non-mechanical" is specious - again, using formulas or variables has no effect upon how the energy / work done is measured.

If we do not move the masses in such a way as to accomplish the interaction, then we cannot measure it. The whole purpose is to measure it!

Think about it - you could set an actuator to apply a constant velocity - would that be a "mechanics in play"? What about if you then used a data table input to vary the speed during the sim - is that still "mechanical"? Equally you could set "acceleration" for the same effect. Or, likewise, you could set "length", and use a data table to adjust the length according to timestamps. The length/time delta will determine the acceleration, and the mass being accelerated determines the inertia, along with any other forces it's subject to. Ultimately, they're all working the same way - F=mA, A=F/m and m=F/A. None of the default input controls determine energy or work - these are only ever calculated independently from the actual F*d integrals - whether by WM's internals, or external spreadsheets etc.

In short, the bleedin' speed control commands aren't the bleedin' energy inputs!? None of the actuator inputs would ever be energy inputs, under any circumstances!? The "energy input" would only ever be the work done - the 'actuators' themselves are lossless and utterly energy-agnostic. It's just a motion control, not the measure of its energy, nor work apportioned..

Nevertheless the energy budget is still the key.

Precisely.

IOW's from the positions of the weights at various frames the system will have Angular Momentum and RKE. There is little doubt that moving the Red weights to CoR whilst swinging thru bdc increases the height the pendulum would normally swing to.

Yes, that's the whole point - if we're extracting GPE into PE, then there won't be enough GKE to make it back up.

The real purpose of the MoI variation however is to slow down the drop.

The more time we spend gravitating, the more momentum we gain. That was the original plan.

IMO the difference in end GPE from Red weights locked at rim to Red weights at CoR is the energy available for the push to center. Obviously if that transition to center happens very quickly the higher will the mech swing.

ME's not leading me astray. We're simply having a side discussion about what might happen and why. If you end up proving your case convincingly then I'll be the first to my feet raising a glass to you.

"The energy available for the push to the center" is reportedly OU, and massively so the faster the RPM's, up to some crunch point where it inverts into a massive non-dissipative loss.

There does appear to be a small, yet persistent GPE asymmetry, in the net of output GKE and PE clawed back from GPE as the weight reaches 9 o' clock - it's always very slightly above GMH. However i'm doggedly ignoring this for now - no one hates GPE asymmetries more than me, everyone knows this, however this is NOT the main issue!

The really vexing problem is that the input energy to the actuators is less than the work done by them!

This discrepancy grows with velocity.

It gets so large, it actually inverts, and starts paying out.

A lot

Then it climaxes, and reverses, turning into massive losses.

That's the issue. Not the (microscopic) GPE asymmetry...

[MrVibrating]

If I'm correct about the Actuator set up that way then it would neatly explain the similar cost of energy each cycle, yet the rpm increases. Food for thought. Hope I'm wrong.

LOL How would it "neatly explain it" - sorry i don't see that at all.

The radial actions affect everything - all the meters, bar MoI, are affected by the inertial torques if nothing else.

CF's going down because RPM's go down, because MoI's going up, so CoM kicks in and applies negative torque.

I'll post another slo-mo anim if it'll help clear things up.. obviously, i'm still seeking answers myself..

P.S. you could swap out the Actuator 'Piston' for a Rod element. In the Rod Length field put in your IF statement formula. It should work exactly like the Actuator using variable Lengths to determine position of the weight, IINM.

Hadn't thought of that, and it'd certainly look neater - might help focus attentions on the bleedin' mass accelerations rather than the actuators syncing them, too, good call, will give it a try...

[MrVibrating]

..just fishing around ATM, trying to feel out this 'knee of the curve' where the gain shoots up before crashing back down into loss territory. Presumably, there has to be a 'unity' threshold somewhere in-between... could be useful to analyse if we can locate it.

Here's a half-decent boost anyway:



...we're now being told that the input energy to the actuators (in avoidance of doubt, yes, you read that right) is minus 628 J... IOW, to perform 23.5 J of work, they spent negative 628 Joules.. IOW, they gained that much PE.


Lazy guesses are two a penny - error, or 'something else', there must be an empirical solution.

And dissecting the interaction should reveal it..

What exactly is in the negative portions of the integrals, below the zero line, and what's in the positive areas above? The current result is obviously their sum, so we're looking at a bottom-heavy / top-light situation - there's more negative work being done as the masses move outwards during the first 90°, than positive work being done as they move back in. Why could this be?

Again, the answers must be right there in the data. Anyone with a studious eye could suss it before i do..

Personally, i've no idea at this point. The data's saying we've caught a dragon by the tail.. that usually means summink's gone pear-shaped.

Then again, just look at how intrinsically messed up an interaction it is - the per-cycle CF workload is fixed, invariant of RPM, net KE is going down whilst it's being accelerated by gravity, even though at lower speeds, net KE would be doubling the instant that radial KE kicks in..

It starts out weird, with strange properties - all of which only arise when the masses are moved in and out whilst the weight's still falling - split the MoI variation between rising and falling strokes, and we can gain momentum, but input and output energies remain symmetrical, and CF rises with RPM. The divergence between input energy and work done no longer occurs.

Yet with rising speed, things get even weirder. At lower velocities, the gain margin's so small you'd miss it unless you were specifically looking for it, and then, at half-decent accuracy.

But speed up, and the margin appears to widen exponentially.. before dramatically crashing back down into a presumably non-dissipative loss (acceleration damping eliminates this, plus the ever-rising simulation frequency).

It seems to defy all rational explanation.. but the answers have to be in those under/over curve integrals..

..that's what i'll be trying to suss next.

[MrVibrating]

..just thought - WM's rods won't have a 'velocity' control field, which is what i'm currently using (rather than 'length').

But by the same principle, we could do away with actuators of any kind, and just program the motions directly into the mass's 'x' and 'y' velocity fields. We could derive a formula for it, or use a data table.. but the work done would still be a function of the force times displacement, and the force would still be a function of the rest mass, gravity / CF force, and acceleration. The same sums apply. The 'actuators' are just a visual reference. They're massless, 100% efficient and child-safe. They're not even real actuators - it's just a graphic you click on to enter the numbers that will move the masses which actually determine the forces and energy / work done.

It's unfortunate that i should need to keep explaining this.. but it's a withering distraction from the real points of interest..

The anomaly seems consistent with the effects of an N3 break. The per-cycle momentum yield would be the key to connecting those dots, but i haven't got to analysing it yet..

Equally, it could be an error, albeit with perplexing dependencies..

..but it's a discrepancy between measures of input and output work to and from the 'actuators'. It's speed-dependent, but not simulation frequency-dependent.

Both measures - for input, and output, work - are using the same dimensions, of force times velocity times time.

The only difference is, one is actually 'sensed' directly from the actuators themselves. This is taken as the force from which "input energy" is calculated.

The other is simply calculated from first principles - it's just the standard CF force formula (mass times angular velocity squared times radius) plotting a rolling update of how much CF force there is as a function of those instantaneous values.

Both of these independent measures are then multiplied by the radial velocity the masses are moving at, and then integrated over time to provide input and output energy integrals - literally comparing the actual energy spent by the actuators in terms of their force times displacement, against the actual work accomplished in terms of mass times CF force times displacement.

At lower speeds, or when the MoI variation is spread across both 'up' and 'down' strokes, both those measures read near-identical values, as you'd expect.

But as speed increases, they diverge. Like, really, really dramatically. Like, inside-out-y, back-to-front-y type stuff. Like WT actual F?

We're measuring frickin' input energy.. That's the whole problem!

[Fletcher]

Then I may make a suggestion or two.

It's about rearranging your sim multiple ways as a means of physically cross-checking outputs for integrity.

For example, don't use the small push start unless you must. Start it off slightly imbalanced with gravity force only. If you need to give it initial impetus because the 'gain' is only there after it crosses tdc into the second cycle etc with some speed then so be it. Use the push start then but it has to come off the energy budget.

Replace the Actuators with Rods. Reasons given. Then it is obvious to anyone looking in that any calculated energy surplus is a result of either the weights radial positional change or more likely the radial weights speed of positional change.

You should be able to create an Output that shows your calculated energy surplus i.e. not actually used to shift weights radially at this stage. This can be compared to Cf's etc for Nets etc. Now make a CONTROL fake force somewhere in the sim extremity (the force does not actually push or pull something, its off to the side). Have the force strength vary and reflect your Energy Output by feeding the Output into the Force Fx and Fy Newtons. When you run the sim the controlling fake force will wax and wane presumably.

Then take out the Rods and replace them with Force elements that rotate with the body. In the Fx and Fy fields put in Output[abc].y1 or whatever. Use If statements in the time field if you have to to turn it off and on, for timing purposes.

Now the fake force in the sim pushes and pulls the radial weights and should wax and wane the same as the control fake force you can see (mirror it) and matches your Output calcs.

So you haven't actually designed and built a physical mechanical lever to do the pushing and pushing. You have gone half a step towards that by isolating the force portion and using it directly to push the radial weights against Cf's etc.

Just another means to cross-check your thinking.

[MrVibrating]

Mate, we're looking at a one-eighth of a Joule kickstart in a cycle that gains 23 J every cycle, after dropping and re-lifting 39 J of GPE. It's fundamentally no different to subtracting it in PE form as you suggest, with the difference that we have to wait for the bastad to topple - plus it skews any measure of an up vs down momentum / time asymmetry, which depends on a non-zero RPM.

Moreover, just look at those speed test results i posted (that was a shedload of work, and not without good reason) - the gain's tiny at starting speeds! Below measurement error, unless you were making high-precision checks - and then, for what reason?


Yet speed up, and it scales up (and how).


So we need speed, in order to measure this divergence it causes.

Replacing the actuators with rods means reverting to using length data. This makes acceleration damping more difficult - doing it with velocity control currently almost fills the equation field. I'm not saying it can't be done, but unless it can, rapid decelerations will be effectively dissipative loss mechanisms - masses race into the center, rod goes taut, KE dissipated.. big loss per cycle.

If you're willing to write down that loss and 'pretend' it was neatly offloaded into a spring or something, then we could try it..

Ultimately we'll still be calculating the forces acting on the rod as a function of CF and inertia, and multiplying that by radial velocity to integrate it over time.. so we'll have spikier, lossier data but with the exact same provenance and dimensions..

Too late tonight anyway.. (eek! 5 AM!) Maybe tomoz...

Calculating the gain from within the sim would mean building a Riemann 'integration engine' just using meters and inputs / outputs as variables. Maybe it could be scripted, dunno.. Again, i'm not saying it can't be done, but i gotta spend the rest of the week doing the work slog, and every night's a late finish, so..

I think i get your point about applying disembodied force elements - obviously, forces not applied against some other mass in the system are an N3 violation, and i agree that only the force should matter, if that's your point - accurately controlling the mass positions using force data alone sounds like a challenge tho - ie. stopping 'em and recovering their KE, etc., could be a lotta head-scratching getting it to work, but would the resulting forces be any different? Surely force is force, F-MA?

See if you can get an example to work, you might be onto something.

I'm gonna continue by taking a closer look at what's under vs over the zero line on that input work plot. 628 Joules payout, for doing 23 J work. It's insane, whatever's causing it..