Blood From Stone

[MrVibrating]

OK, here's how my w/e went:

• realising that the faulty 'direct' measure of actuator energy afflicts all results going back many weeks, it seemed prudent to retest the previous axial-to-orbital results, using only calculated input energy

• this showed that the most recent version of that rig - which retarded the clutch-engage angle to mix in some regular 'OB' torque - converges to just 32% efficiency

• the previous version, which engages the clutch just after the weights return to TDC, converges to ~99.7% efficiency


This is an interesting, and telling, result... what it reveals is that:

• the previous version converges to near-unity because the initial speed difference between axial and orbital rotations is large; the orbit begins stationary, and is only nudged into motion by a succession of 'collisions' with the axial rotors, via the clutch..

..and, as more and more orbital velocity is built up this way, that speed difference closes..

..until eventually, the increase in axial speed each cycle is only slight, compared to the already-up-to-speed orbital velocity..

..hence there's simply very little relative RKE difference between them - very little momentum to be imparted, and very little energy to be dissipated by the clutch!

Simple and obvious, really..

And if "99.7 % efficiency" still sounds OK-ish, consider that this simply refers to its coefficient of performance - the amount of axial work that gets converted to orbital work, after standard copper losses and friction etc.. so it's not simply worse than a standard motor, it's all but useless since it can apply so little torque - since it's only being spun up by these poxy little 'collisions' via the clutch..


If we simply refer back to the mere concept of gaining KE from an effective N3 violation, it depends upon the 'accelerated' mass actually being appreciably accelerated, relative to the 'non-accelerated' mass.

Doesn't mean it has to be an exact 1 m/s (or whatever) acceleration every time, but if it's starting out as a large relative acceleration, and then quickly dropping to an almost negligible one after a few cycles, there is FA momentum to be shared back via the collisions, so its frickin' energy cost is kind of moot..

In short, it ain't doing the business..




But what about the last version, where the axial rotors are braked against the orbital rotor just as they reach 9 o' clock horizontal, thus applying brief pulses of 'over-balancing torque' directly to the orbital rotation; this locks in on 32% efficiency...

...so, what that means is that the other 68% of input energy is being consistently dissipated as heat..

...this means that the relative velocity between axial and orbital rotations remains large, consistently...

...this means that there is significant momentum being imparted, hence its cost of supply is very much a 'going concern'..



...however, again we've struck dry dirt - the above conditions would only be favourable if they applied to the energy being input via the actuators.,

..whereas, by dropping the clutch as the weight's are halfway through their fall - and thus at mid-acceleration under gravity - most of the energy being converted to heat by the clutch is simply GPE!

As the weights pass TDC they start to accelerate downwards under gravity. Then we're braking that descent, and converting most of that 'GKE' into low-grade heat.. but with it, most of the momentum gained from gravity.. hence ruining the whole point of having an up vs down momentum asymmetry in the first place! If you wanna be accumulating momentum from gravity, this evidently ain't the way to go either..


So this whole MoI-backflip scheme appears to have run its course.

What is useful, is being able to accumulate momentum from gravity, and while it does that, so does a simple radial retraction or extension, as already demonstrated.

Mechanically, that's obviously not a particularly ingenious accomplishment. But appreciating it for that singular ability to add momentum, asymmetrically, from gravity, is a huge leap forwards, considering some of the madcap schemes i've tried to accomplish this previously - all this time, there was an easy way!

So now a new scheme is required, in order to capitalise on that breakthrough and maybe do something more useful with it..

And for that, i'm gonna need copious amounts of whisky, Radox and hot water. Don't worry, never fails, back once it's started working..

[MrVibrating]

Oh, and because of the above findings, i didn't bother trying the new actuator firing pattern, since it obviously nets half as much momentum (because MoI is only high for half the fall, rather than all or most of it) - it'll cost half as much per cycle, adding half as much momentum and one quarter as much RKE, but still converging towards unity as orbital RPM's rise to meet axial RPM's..

Having a speed-invariant input energy is only useful if it's buying constant momentum per cycle, or at least, an amount that doesn't diminish by the inverse square of RPM, per ½mV²... otherwise it's a just Pyrrhic victory, bankrupting the momentum supply, defeating the whole objective..

[ME]

In short, it ain't doing the business..

Well that's all very nice for you to discover...

So what about that attitude in this whole topic?
oh, I'm still on ignore :-|

[Georg Künstler]

Hi Me,
it is always easy to use the "Trampelpfad,trail", then you can not make errors, because others had made the errors for you.

We have to find new ways, the "Trampelpfads" are know.
Try and error, try and error, until you get the solution what you try to achieve.

So I appreciate MrVibrating for leaving the "Trampelpfad" and has searched for new ways.

BTW.
you ever have thought about a positive feedback loop ?

https://en.wikipedia.org/wiki/Positive_feedback

[ME]

Depends on the short-cut
MrVibrating didn't take a shortcut route, he took a route right into the swamp and yelled numerous times it was the best parking space ever.
Lucky that some saw it for miles; there are some who blindly followed; there are some who just like to see him go.
Now I question: what is the desired way to react?

Sure, a bit of enthusiasm and exaggeration is to be expected here and there.
You try some, you learn some. Suspect things may work, test it out, calculate a bit, perhaps even build it...
Don't worry, I have my own share of errors.

Feedback, yes...
With a positive feedback-loop things grow out of control.
With a negative feedback-loop things can stay in control.

Indeed, we want positive feedback to make perpetual motion machines go.
But we need negative feedback for ourselves and peers, because that's the oh-so-needed self-critique for study, learning and a way to keep our feet back on the ground.
It keeps us from losing our fingers because of 'too much enthusiasm'.
That's not "negative" as in "depressive", that's "negative" as a "control-feedback-method"...
IT"S SCIENCE.


What are we now supposed to do with this conjecture-based "language of overunity", as he calls it.
It wasn't verified to begin with, and now its not true either...I already had to correct this "buying momentum" because it was no longer at square prices... (or something)
Anyway, he's the one calling it "scientific".

There's real science here, and no good reason for this subject not to be taken more seriously.. but for the stigma of association with the peanut gallery. The scientific method's free to use, we can lift ourselves out of the fog anytime, it's an entirely self-imposed status quo..

That's all his prerogative, until other people on this public forum get dazzled by all bling-bling and start taking his word for it and awe at his "magical thinking".
So let's take it serious, because – does anyone have a better constructive alternative? [That's the second serious question]

Hence, on this public forum I try some sort of peer-review: you try some, you learn some.
It's always possible I make a mistake too, just point it out in relation to the correct subject and then it simply adds to the explanation instead of making it personal or a tuck of opinion.
I think that's a beautiful way to add things.
Now we have the situation of... oops, eehm oh well didn't work. Let's forget like it never happened...

Now I ask: what happens next?
What happens to all those conclusion?
What happens to "the language of overunity"?
Back in the fog... but back from the clear, or back from the dirt?

Important questions, if you want to learn something.
I'm afraid the next topic will likely be as misty.

[silent]

.

[WaltzCee]

oh, I'm still on ignore :-|

Nah, he's just giving you the silent treatment. On the bright side
we have a very (f?)soggy rope.

One cool thing about this forum is there are some very sharp
minds here that average people like myself can benefit from.
You never know what might cause someone to begin thinking
along lines that aren't being discussed.

For instance, when trying to game N3, consider that all these
equations are some what sort of tied together creating (as
Cloud Camper noted) a symmetry. The answer? Get an
eraser out and start eliminating things. Cross out a variable
here or there. Also make sure what you're building can
actually erase some of the bologna. Bologna = EG.

Get rid of it. You don't need it. That's my 1.5 cents.

[MrVibrating]

W/E plans...

Analyse this:




..came up with it a few weeks ago, left it on the backburner til now...


What the hell was i thinking? 'Nowt new - gain momentum from gravity at an energy cost that doesn't square with rising RPM.


Logic: classic OB with a radial lift seems the simplest way of causing an asymmetric inertial interaction between 'the system' and Earth. OB torque induces lashings of momentum-from-gravity, whereas radial lifts give back very little, if any.

The other great thing about gravity as a momentum source is that GPE is of course speed-invariant - the cost of raising a weight doesn't rise with RPM, all else being equal.

The CF workload does of course increase with RPM, and so the above scheme is yet another attempt at meeting that challenge, inspired by earlier findings in this thread.

Initial attempts to measure it were still using the direct measure of actuator force that we now know is faulty, so instead, the work done will be measured using CF workload and GPE meters.

The basic concept is a conversion of GPE into outbound CF work, whilst the extending MoI restricts RPM growth - although it will be worthwhile measuring with and without this latter condition in effect (ie. red masses parked at center). Obviously, CF still grows with RPM, but output CF work should also be consistently greater than input CF work - subsidised as it is by GPE - so could this help cause a self-perpetuating loop, if not, why, and what further use or developments might be deduced from it..!?

Nice easy one this time, with any luck...

[Georg Künstler]

Hi MrVibrating,
have you ever tried a eccentric-wheel in wheel construction ?
Not like a gear,
when both turn in the same direction, then gravity can work for you and accelerate the outer wheel,
you generate a standing wave.
like
http://www.alt.kuenstler-energie.de/
on the logo in the right upper corner.

And you have 2 systems, which can swing, one against the other.
The key to extract energy from gravity is fast up and slow down.
In your simulation you have no second force, so that amplitudes of the swinging can be added.

[MrVibrating]

Right, that last rig was a bit of a multi-purposed WIP - i'd re-used the same components to sketch out a number of different interactions - so here's a dedicated scratch-build:



..currently the vMoI component (in red) remains inactive - we'll bring it into play after taking some baseline data from the weight-only (green) interaction.

Furthermore, since we presently have two cycles per rotation, i'm going to deactivate one of the green actuators, so that we're left with a single interaction per rotation, like this:



..this just keeps the data as clean as possible. Anything interesting turns up and we can re-enable the other green actuator any time.



So, the area of interest is the relationship between input/output GPE vs input/output CF/CP workloads.

We can already see the anticipated greater areas in the upper CF work integrals, compared to their lower counterparts, and representing a conversion of GPE into output CF work.

Let's begin by establishing how this dynamic unfolds across some range of rising RPM's.

Then we can consider bringing in the red 'variable MoI' component, and how this will affect the resulting energy and momentum distributions.

The ultimate objective remains unchanged - gaining momentum from gravity at an energy cost that does not square with rising RPM's; buying it on the cheap, basically.

There's no expectation that this interaction will be able to accomplish that - it's just an investigation, that will hopefully provide further food for thought in attaining that goal, ie. what works and what doesn't, how and why, and thus by elimination, at least clarifying the priority obstacles to be overcome - hopefully shining a little more light on the implicit, if not explicit, path to OU..

..just tying up a few loose ends in my head, if not anyone else's.

[MrVibrating]

..bit more spit'n'polish:




..the added 'net KE' meter shows that the sum of rotational KE plus radial KE - both being calculated on-the-fly from first principles - is watertight with WM's internal 'kinetic()' measure of net KE using its own low-level calculus, and impervious to my fat fingers..


So, the GPE's, CF workloads and KE's should all square neatly at whatever speed - again, the immediate objective is not an energy gain, so much as further elucidating the practical constraints on manifesting a gain condition - specifically, the factors causing either input energy costs of momentum to square with velocity, or equally, those causing the per-cycle momentum yield to decrease by the inverse-square of velocity, to the same net effect, of enforcing mechanical CoE, per ½mV².

For clarity, we're no longer looking for an effective N3 violation - to all intents and purposes, we're already looking at one; a closed system of interacting masses rotating about a common axis, gaining momentum without recourse to a stator. This appears to be a textbook violation of N1 and 3, already..

..all we need now is to keep its energy cost of implementation down, to start reaping the benefits, and the only apparent barrier in our way is rising CF workload / diminishing momentum returns as RPM's climb..

..hence the current scheme, of trying to part-subsidise the CF workload with GPE.

Obviously, with the red masses parked-up at center, RPM's are going to rise over successive cycles, and with them, so will the CF/CP workload.

Accordingly, we'll also expect to see a decrease in the per-cycle momentum yield, as less overall time is spent gravitating per cycle, both up and down.

Presumably, the maximum per-cycle difference between CF input and output work will be equal to the difference between output GPE and rotational 'GKE'.


However, if we bring the red 'vMoI' masses into play, then by controlling their rate of extension, we can slow or mitigate the RPM increase, and hold it somewhat stable across some RPM range..

..hence maintaining 'time-spent-gravitating' per-cycle momentum yields across that RPM range..

..and also the 'green' CF I/O workload..

..whilst accumulating PE in the 'red' actuators (as a function of their negative CF/CP work), instead of accumulating KE..


..obvioushly, if we then allow that 'red' PE to unload back into the system, the red masses will be retracted as if by sprung PE, converting directly to rotational KE, yet without changing the net momentum (ice-skater effect / CoAM), and so with any luck we'll end up with a maximal yield of momentum-from-gravity, for minimal input energy. If we're extra lucky and hit OU, job done, but if not, we'll only be better off for understanding precisely why..

Again, the 'minimal' theoretical cost of momentum per cycle, as set by ½mV² and ½Iw², is just half a Joule per kg-m² or kg-m²-rad/s. If we can maintain that for just two cycles, we'll have spent 1 J to buy 2 p of momentum, that actually has 2 J of KE, so a 200% OU result.

As ever, OU doesn't require that rock-bottom ½ J per kg-m² condition - the actual energy cost of momentum could be literally anything - a megajoule or more - but provided it's simply stable over some speed range (or at least, not squaring with speed), that's still an open goal, and primed with sufficient energy a system can still exploit it..

But enough vamping... the sim should now contain everything needed for a full e/p accounting.. it's data time.

[MrVibrating]

..hmm.. just realised, we could simulate hydraulics quite easily - consider some kind of bladder at 12 o' clock, and another down at 6 o' clock, connected by a radial pipe:

• the volume of fluid in the connecting pipe can remain constant, hence its mass distribution remains constant, no matter whether fluid's rising or falling thru it

• hence mass can pass seamlessly between TDC and BDC, without incurring any CF work at all - positive or negative..

It's a bit of a diversion from the current scheme, but hell, maybe this is one lesson intended via the 'bellows'-type mechs in MT..?

Come to think of it, it's the same net result as 'changing GPE without changing MoI' using that speed-control trick shown a few pages back..

..so maybe here's somewhere we could try implementing such an exploit? Ie. instead of trying to turn the CF workload to our advantage, why not just eliminate it altogether?

Then the per-cycle input energy would be constant - just the input GPE would remain.

All we'd need then is a means of maintaining the per-cycle momentum yield - and hopefully, the above vMoI-braking technique should do the trick..

Will proceed taking data from the current rig for now, having done all the prep.. but we can sim these fluid-filled 'bladders' simply by making the value of two opposing masses covariant with respect to one another.. ie. decreasing and increasing in direct inverse proportion, at either end of a central solid interlinking member of equal relative density! That's yer basic 'hydraulic system', in all but slosh and leaky seals..

Either that, or else the actuator-speed trick that does the same effect; eliminate CF completely from the GPE interaction, hence stabilising p/c input energy costs irregardless of RPM, and allowing us to concentrate on maintaining the p/c momentum yield.

Plan.

[MrVibrating]

Hi MrVibrating,
have you ever tried a eccentric-wheel in wheel construction ?
Not like a gear,
when both turn in the same direction, then gravity can work for you and accelerate the outer wheel,
you generate a standing wave.
like
http://www.alt.kuenstler-energie.de/
on the logo in the right upper corner.

And you have 2 systems, which can swing, one against the other.
The key to extract energy from gravity is fast up and slow down.
In your simulation you have no second force, so that amplitudes of the swinging can be added.

"Fast up and slow down" is a punchy mnemonic - what we're really talking about tho is of course relative momentum yields.

GPE, for its part, is of course speed-invariant, so it's important to emphasise that we're talking about a momentum asymmetry, rather than an energy asymmetry, in the first instance.

The key to understanding why it works tho is that "gravity" reduces, from the mechanical perspective, to an ambient time-rate of change of momentum.

Gravity's not a 'force' per se, since F=MA (Newton's 2nd law, a la 'N2') - per Galileo's principle, it's a uniform acceleration, invariant of mass; a feather and rock fall at equal speed in vacuum.

And what is 'acceleration', but a rate of change of momentum?

Hence the key detail is that the total change in momentum is a direct linear function of the time spent gravitating - whether decelerating upwards, or accelerating downwards.

But gaining momentum alone is only halfway to making KE from it - this is the aspect i'm currently working on.



As for the types of design you mention - yes, if i understand correctly, i've tried many variations on that type of system - essentially, the over-balancing arms / levers / weights are being used as a 'stator', hence the system cannot break N3 or thus gain energy.

Using your graphic linked above as an example:



..the 'axial' speed of the orbiting rotors is a fixed function of the orbital velocity. They can only maintain that off-balance angle via the constant supply of torque, and the integral of that torque around the 360° of angle (axial or orbital, since they're in-sync) is equal to the rise in rotational KE.

The best you can do is to hide an internal stator, and use it to generate torque by allowing the weights to get lower over successive cycles, like this:



...the rate they fall at - essentially, the axial-to-orbital velocity ratio - is controlled by a gear ratio, hence if losses are kept low enough, the weights can drop very slowly, over very many orbital cycles, and thus gaining impressive speed... albeit, with all the power of a wristwatch..

The solution to these issues is what i'm currently working on.

In your graphic, not only does input energy increase with RPM, but momentum yields also decrease with RPM - so it comes up against the very same factors i'm wrestling with in this thread; in a nutshell, ½mV² / CoE.

OU - 'excess mechanical energy' - basically reduces to "gaining more momentum than we've paid for" - or at least, buying it on the cheap.

And that means getting to the nuts and bolts of how ½mV² / CoE is enforced! The most basic basics... force, mass, motion... and time..

[MrVibrating]

OK, so i've taken that last sim (dt3131) and simply maxed the frequency for the test period:

• those 4 revolutions take 5.9380 seconds

• max no. of frames per sim is 32765, hence we divide that number by the above period to get a freq of:

• 5517.8511283260357022566520714045 Hz precisely.

The final frame looks like this:



..so, nice and clean (eliminated that final amplitude spike off the end) - everything appears sane & consistent.


The key integral to take, then, is the "CF/CP Work Done" - this meter calculates the instantaneous centrifugal force, multiplied by the radial velocity, and then integrated across the 5.9380 seconds. The equation used looks like this:

Code: Select all

((input[25] * Body[1].v.r^2 * length (23, 1)) * Constraint[31].dv.x) + ((input[25] * Body[1].v.r^2 * length (22, 1)) * Constraint[37].dv.x)

Where:

• Input[25] is the "Weights" mass input, currently set at 1 kg

• Body[1] is the central black rotor hub, and v.r^2 is its angular velocity squared

• length (23, 1) is the distance between green weight 1 (body 23) and the rotor hub (body 1)

• Constraint[31].dv.x is the speed of green actuator 1

That formulation is then repeated in parentheses for green weight 2 (body 22) and green actuator 2 (Constraint[37]), summing both products together with the central "+" sign.

So the formula is essentially "mass times angular velocity squared, times radius, times radial velocity, times time"; m * w² * r * rad_vel * t.

We could also think of it in terms of "centrifugal power times time".

This metric has proved extremely accurate in all other tests thus far.

Remember, the error-prone metric of "actuator force times rad_vel times time" is perfectly accurate at low speeds, and in agreement with the above CF metric, down to the millijoule.

We've solved all of the other systems, to unity, using the exact same energy term, even where the "actuator force" version started getting scatty at higher RPM..

So, with these points in mind... looking at the above sim results... you'd expect the CF work integral to be pretty-much spot-on 32.6749 J, right?

I mean, we began with 0.25 J. So, minus that, the CF work should be within a mJ or two of 32.424 J.

Because that's how much the net KE has risen.

So... ummm... you can see what all this is building up to, i suppose?

Yep. Damn. I'm really sorry guys, honestly not doing this on purpose...

The CF work integral comes in at 27.92296864 J.

32.424 - 27.92296864 = we have ~4.50103136 J more KE than we've paid for.

I'm sorry, i'm crap at this, mea culpa and all that... but we only appear to have done 27.92 J of work against CF.

GPE can only be a zero-sum... and the only other work there is CF! 'Da fuck?


There's a few other points worth noting:

• we don't need no stinkin' integrals to see that per-cycle output energy is already constant - go back to that last sim, and note that the net KE increases by exactly 8.11 J per cycle, every cycle - so we already have speed-invariant input energy, it would appear...

..this seems to be something of a trademark of these types of systems! Keeps coming back in different rigs, doesn't it?

This behaviour's in stark contrast to most types of motor, in which per-cycle input energy must inevitably increase with RPM's...


• however we can also plainly see that the momentum yield appears to be diminishing - the 'steps' are getting progressively shallower each cycle...


...so, this would seem to justify the go-to presumption that instead of seeing input energy rise with RPM, we're seeing the corollary effect, of momentum yields decreasing by the inverse square of RPM, to the same net effect, right?

Obviously, the next step will be to measure the momentum one cycle at a time (or even fractions of a cycle, at max simulation freqs), to establish precisely how the yield's progressing... is it possible that the decrease is slightly less than the inverse-square of RPM - hence an effective KE gain?

4.5 J is quite a lot of energy when we're at four sig-figs precision already, but further raising the accuracies should enable pinpointing its origin..

Suffice to say, the original intention was to start winding out those red masses, to apply a negative inertial torque, slowing the RPM rise and so keeping the 'steps' on the momentum plot equally-steep.

The idea being, that if we can achieve both a constant momentum yield and constant input energy across some RPM range.. that's basically "OU" in the bag.

Yet we haven't even got that far, and we already have constant p/c input energy, plus we're 4.5 J OU, from an energy term that's millijoule-accurate in all previous usage..

4.5 J. That's enough energy to heat a very small mug of cocoa.. to plasma! Like, a mouse-sized mug, anyway. Or maybe for a large spider. Whatever.. i wonder if cocoa plasma still tastes chocolatey? Sounds like a Heston Blumenthal thing, might have to crank-email him later..

[Georg Künstler]

Hi MrVibrating,
I had build many versions of my construction.

You can see it under,
http://www.kuenstler-energie.de/index.php?id=9

There are 2 different outcomes when I compared the gear version with the chain version.

In the gear version their is no space to live, everything is 100 percent perfect

The chain version has this space to live, in the gaps of the chain.
The forces which appear were very strong and the chains are broken now.
You get a time difference between up and down.
This 2 mm gaps in the chain were enough to let the mechanism live, breath.

In my opinion: the chain version is a resonance version, dealing with gravity.