Success..?

[MrVibrating]

Best night's kip in a couple of weeks, last night..!

No problems whatsoever on accepting my idiocy as a full and complete resolution of this wearisome little episode..


But just to finish off crossing the i's and dotting the t's, i thought i'd try a few more runs with various settings, just check it all sums consistently to unity..

..cuz that last one, remember, was still showing a small gain..

..so i further raised the masses of the smallest parts..

..then i set TRS to '1 rad/s', and simmed 1 full turn of the system at max freq..

..here's the results:



Acts = 153.9546007

Motors = 23.01353861

Brakes = -20.41572463

Sols = -4.590990401

Total PE = 151.961424279



EPE = 0.000147

KE rise = 156.708815

Total Out = 156.708962

Diff = +4.747537721 J


Sim attached.



So now i invite anyone else to find further errors - i mean, it took me ~2 weeks to notice i was applying sharp braking forces to vanishingly-small masses, and as much as i'd like to blame being over-tired from work, it's a stupid thing to overlook, so who knows what else i've missed..

Because honestly, i expected this to solve neatly to unity by now - anyone familiar with WM and the kinds of results i usually take for closure (ie. within millijoules of unity) will appreciate that 4.7 J is too large an error to be ignored...

This is just the first spin i've given it since prepping that previous sim the night before last - i'm still working weekends but will try knock out a few more after work tomorrow..

Obviously, considering how many configs i ran thru before noticing the aerogel components, it's silly to keep trying to optimise this further until one decent sim has been fully audited and understood, so i'll try to quickly settle on what seems like a solid, consistent anomalous result and just tear into it until all is laid bare.. maybe this one here would even do - 4.7 J is enough energy to accelerate 1 kg to 3 m/s..!


Sorry again for all the drama, bit of a rollercoaster as ever.. i thought i'd killed it, but it appears to be toughing it out..

[MrVibrating]

OK here's a start - let's actually run the momentum * time test i've only previously alluded to:


• with spin'n'brake cycles disabled, note the momentum yield of say 1 full turn from OB-torque only

• compare the yield from a 'live' run over the same range of system angle

..if it's real, then we can only be gaining energy if we're also gaining momentum - indeed, the KE gain will be directly proportionate to and dependent upon the velocity component of that momentum gain..

[MrVibrating]

Damn...

..took that last sim, set TRS to '0' and let it run the same full turn:



Motors = 0

Brakes = 0

Acts = 157.390078

Sols = -4.920762655

Total In = 152.469315345 J



EPE = 0.006404

KE rise = 158.189171

Total Out = 158.195575

Diff = +5.726259655 J



Eek!

WTAF?


Well, that's gotta help simplify the analysis, anyway...

Dunno what else to say for now..


!

[MrVibrating]

How can there be gain on both the actuators and bloody solenoids now?

Did i ever really baseline the OB system that rigorously before? I'm not sure, you know - i thought i'd established it was a zero-sum, but maybe that was based on false assumptions?

If this result's correct then the s&b cycles were only ever impeding the real gain mechanism..

But why would a constant-MoI OB system be inherently OU..?

I was honestly relieved last night when i thought this was over..

I mean the actuator code's basic - change length as a function of 'timing wheel' angle. No FFB. It definitely solves to unity normally - tested it countless times. Happy to demonstrate it again. But now it's showing gain..

Such gain can only have been harnessed via the CF integrals, if real, so this should be solvable one way or another..

..i mean it can't've come from the solenoids because they're gaining too (ie. net work's being done against them - so their net area's below the 'zero' line) - so CF force should be able to account for both these gains, surely?

I only intended to compare the momentum yields.. but even there, it appears the so-called 'dry run' gained more momentum in less time, for the same full turn..

the spin'n'brake cycles, and their seemingly-stupendous efficiency envelope, were only ever limiting momentum yields and OU efficiency!?


This is messed up, there's gotta be some other error...?

[MrVibrating]

Right, dunno what i was doing at the time, but baselined the OB mech here back in June last year:



sols = -0.015203456

acts = 116.2259719

Total = 116.210768444

KE Rise = 116.22587

Diff = +0.015101556 J


...millijoule accuracy, case closed.. at the time, anyway..

So the only thing different in the current rig is the addition of the timing wheel, and also, the weights here have been changed to low-mass 'sliders' on keyed slots, which the new 'rotor-weights' now attach to via their motors and brakes..

So basically, either that timing wheel's causing impromptu OU, or else it has to be some error introduced elsewhere..

The basic OB trajectory tho definitely seems like a zero-sum here..

[MrVibrating]

I can't find any more potential error sources in the v1_1 config.

Doesn't mean it's real, yet - the above unity sim from last June was taken at 100 i-s/f.. So far in this thread, i've only been using 1 i-s/f.

So i'm gonna repeat the last gainy run (OB only, no s&b's) at the same accuracy as that unity one..

At that point, the only difference is that timing wheel..

I'll record all the data from that run and analyse the CF integrals to see if the gain on the acts & sols correlates..

..if it does, then the implication is that the timing variation afforded by the sprung timing wheel is somehow allowing a net output of CF work, and thus, serendipitous OU..


It's a little lame letting the imagination run wild with potentially ground-breaking explanations for what inevitably turns out to be yet another error, but feck it, it spices up the thread, and it's honest BS.. perfectly OK to be wrong (given our realistic prospects on ever being right):

• without the timing wheel, the input GPE is hard-synced to wheel angle; the tiniest variation in wheel angle causes a corresponding change in length of the linear actuator lifting the weights... as previously discussed in this thread, this hard-couples input GPE to rotKE, mathematically precluding the possibility of ever manifesting rotKE > input GPE, regardless of the source of any further rotKE input..

• with the sprung timing wheel, the above restriction now has some wriggle room; acceleration of the linear actuators can lag behind wheel angle, or even catch up and overtake it, depending on what the spring's doing..

• so maybe this provides windows of opportunity for harvesting back some of the CF-PE being generated by the rotKE..?


• Another aspect that seems intriguing is something i posited earlier - the interaction was designed to manifest 'purified OB' - a constant OB torque, undiluted by the inertial torques - and their corresponding accelerations / decelerations - that normally go hand-in-hand with any OB system, as a base onto which to attach various types of reactionless accelerations.

Additionally, having a constant MoI facilitates asynchronous coordination of any superimposed interactions.

Regarding its efficiency, my logic was that as there's no inertial interaction - ie., no change in MoI means no net work done against CF force - it's a 'pure' GPE interaction, and thus must be symmetrical.

But what if the new timing variation in v1_1 means there is, now, net work being done by CF force, against the acts & sols, subsidising their workloads?

So the loop would look something like this: GPE -> rotKE -> CF-PE and back into GPE.. but how could that cause OU?

Because CF-PE is being harnessed without causing an MoI reduction!!!


Think about it - to harness rotKE via CF-PE, you have to slide mass outwards, increasing its radius, and thus MoI, and so invoking CoAM to cut the speed, conserving their net product, and the rotKE remaining in this subsequent decelerated-but-higher-MoI state is equal to the starting rotKE, minus whatever you took out in CF-PE, right?

But what happens if you're somehow able to harness CF-PE, without causing a corresponding MoI reduction?

If the MoI's held constant whilst you're nonetheless pocketing CF-PE.. and thus the axis is still under smooth constant acceleration under OB torque.. then isn't that CF-PE basically free?


Rhubarb rhubarb, eh.. s'probably just error, ignore me i speak utter shite..


The 100 i-s/f sim's halfway done... results b4 bed..

[MrVibrating]

..here we are:



sols net P*t = -4.920762655

acts net P*t = 157.4118799

total in = 152.491117245

KE rise = 158.192420

EPE = 0.006407

total out = 158.198827

diff = +5.707709755 J

rotor 1 CF P*t = -30.20119117

rotor 2 CF P*t = 30.19850177

rotor 3 CF P*t = -1.502504519

rotor 4 CF P*t = 1.500082499


..so, do the CF workloads help explain the result? Not sure what to make of them ATM...

Notice however that the solenoids plot has a markedly different shape to the previous, 1 i-s/f sim, which was much more sinusoidal, without these sharp peaks... nonetheless, the results are refining the previous gain figures, not changing them significantly.. much less getting rid of 'em..

Weird huh?


The obvious test then is to keep everything identical, except the lag currently afforded by the spring; instead, let's do a comparison run with the actuators' timing signal switched back to referencing the angle of their own axis, whilst leaving the now-redundant sprung timing wheel to continue being towed around... so, exactly the same config, just minus the timing variation..

Will have to wait till tomorrow night tho cuz i'm shattered..

[MrVibrating]

Ok, just in from work and starting the aforementioned control run now - this will go back to syncing the actuators as a function of their own wheel's angle, ignoring the new 'timing wheel' being towed around by its spring..

So that timing wheel and spring will still be there, doing exactly whatever they were doing before...

... they're entirely redundant tho, so if using 'em as the timing source was causing the gain, this should return a neat 'unity' result.. just as the June '19 version does.

Yes, using 100 i-s/f is evidently redundant, too - only shaving a few zeros off the gain - but it also gives me a bit more time to chillax and unwind, get some dinner on etc. And helps sustain the suspense, of course (this is about as exciting as things get around here)!

If this does throw up a zero sum, then the sprung timing wheel is evidently causing the gain conditions..

..and should that turn out to be the case, then the possibilities for error are fast disappearing..



Watch this space..

[MrVibrating]

"Possibilities for error" deserves some context; it would mean i was wrong about pretty much every hypothesis from the thread outset, until hitting on the 'spring buffer' idea - primarily to get rid of the spikes on the actuator and solenoid plots, but also, with any luck, to break, if only momentarily, that hard-sync between input GPE and rotKE.. this latter function being the winning break..

So when i thought i'd 'quadrupled' the gain, that was probably the first time plausible gain had arisen at all.. prior to that, i'm pretty sure, the 'gain' was caused, at least in part, by the solenoids being too light..

But moreover, it would mean the whole methodology of using s&b cycles to try to accumulate a momentum asymmetry was over-complex and quite possibly futile as an objective in its own right.. that the real problem i should've been tackling was the paradox of trying to yield rotKE in excess of input GPE.. now, apparently, solved by something as simple as a spring 'time-buffer' to decouple the two fields..

All i meant of course was that the chances of the current gain result being legit would seem to increase significantly if it really is merely a function of variable actuator / wheel sync..

[Fletcher]

It's always a case of robust process of simplification, elimination and comparison Mr V, in my experience.

Until you "know" what's causing the result and then make sure the results are bullet proof.

I also use standard low mass parts (0.001 kg aka 1 gm) in many of my sims so that the actual CoM is best shown. Then I go back to Properties>Materials and select a real material for that part, be it wood or steel etc. That automatically changes the mass of the object to something closer to reality for that material, and I can change elasticity as well if that is a factor or importance.

Then run the sims again. Rinse and repeat as you used to say ;7)

Good luck.

[MrVibrating]

You're right, cheers mate - if the gain's still there in the 'control' run then it has to be in error..

..if it's a zero sum then i'll switch back to the variable-sync and try make sense of a full audit - so, taking account of the GPE work performed by each actuator, and adding / subtracting the CF work, should give figures matching their integrals; ie. checking whether output CF work really is subsidising input GPE work..

..if the sim's outputting valid data then all this telemetry has to somehow jell into a coherent gain principle!

[MrVibrating]

Well here's the results of the 'control' run:



Acts = 155.8190424

Sols = 3.164513706

Total In = 158.983556106

KE Rise = 155.819349

EPE = 0.006499

Total Out = 155.825848

Diff = -3.157708106 J


Weird huh? When i saw the actuator integral i got excited, assuming the solenoids would show ~0 and hence neat unity... however instead, the solenoid integral's turned positive!

A net loss!?

I was so hoping this run would show a big fat zero, since then the gain result would be at least as 'legit' as the unity control here.. 'cept we ain't seeing unity, maddening as it is..


So i guess the next step is to apply the same physical changes to the 06/19 sim and see if that one loses 3 J too..

But how could a total loss of 3 J even arise? This has to be an error, and likely the same one causing the gain, surely?

Impatient to get to the bottom of this..

[MrVibrating]

..i suspect this last result IS an error, caused by using multiple integration steps per frame, for the following reason:

• at 100 i-s/f, the reactive feedback loop is calculating 100 conflicting torque values per frame - you can watch it doing so in real-time, over then under-compensating; it nails the MoI, but in a very busy way under the hood..


Gonna do one last run before bed, at 1 i-s/f.. results shortly..

[Fletcher]

Perhaps try running with fixed iteration steps, and again as a comparison, with variable iteration steps ? Tick it off the list of things to do.

[MrVibrating]

Well, still don't look quite right to me at 1 i-s/f:


Acts P*t = 155.7993728

Sols P*t = -0.392929136

Total In = 155.406443664



Sol1 T*a = 16.65603169

Sol2 T*a = -17.05550996

= -0.39947827


KE Rise = 155.818698

EPE = 0.006498

Total Out = 155.825196

Diff = +0.418752336


I took the solenoid T*a's too just to verify their net P*t..

3 J down then half a Joule up, just by changing i-s/f... not good consistency eh? There's an error afoot..

Might try variable i-s/f tomoz, knackered now - skeptical, but willing to try..


I can debug it, it's just the frickin' time and work involved.. but then if it IS all just error then there's nothing better to be getting on with anyway, so it's not like it's holding up 'progress', i guess..


Will keep rechecking all code and trying different controls, maybe adding some of the current embellishments to a copy of the 06/19 version to see if it too starts misbehaving..