Hydro Differential pressure exchange over unity system.

[see3d]

Stop right here, because Newton IS rolling over in his grave at this point. If your draining and adding the same amount of water is supposed to be energy-neutral as has been claimed, then why haven't you already made a perpetual water pump? It doesn't have to be the _same_ object weighing the "payload" weight, does it? So after a bunch of your energy-neutral adding and draining water cycles, you could accumulate an arbitrarily large bunch of "payload" weights up at the top of the lift, on a platform of some kind. These could then be used however you like.... and at whatever efficiency level you like. Accumulate a hundred or a thousand or ten thousand of them, for free. Then slide them downhill powering a generator or a water pump.

Or.... perhaps the adding and draining of water is NOT energy neutral. If you are removing the lifted weight at the top, then can you recover the added water at the same level that you added it? Or do you have to provide a "suck" by lowering the receiving chamber much lower than it was when adding?

TK, Think man!  For all your nitpicking about useless details, you sure like jumping to conclusions in the big picture.  If the test is done, the data will speak for itself.  Then you can chart and detail out all the conclusions you like.  I am making no claims about what the data would show.  How could I?  I do not have a ZED built to test here, just a broken simulation that has not yet gone past one layer.  I am just interested in the transfer function of a live ZED to verify the sim.

But I won't be cruel and make you think too hard:

1.  Cycle starts at sunk condition.  No payload weight.
2.  Energy is input, work is done to lift a payload weight.
3.  Payload is removed, input energy is removed.
4.  ZED inputs and loads are the same as 1., so ZED settles back into same state as 1.  Cycle is complete.

You are jumping to some sort of conclusion about about O/U that was not even implied by my test sequence.  Having a prejudice blinds you to what is being presented.  I know all too well... as my wife informs me.

[TinselKoala]

TK, Think man!  For all your nitpicking about useless details, you sure like jumping to conclusions in the big picture.  If the test is done, the data will speak for itself.  Then you can chart and detail out all the conclusions you like.  I am making no claims about what the data would show.  How could I?  I do not have a ZED built to test here, just a broken simulation that has not yet gone past one layer.  I am just interested in the transfer function of a live ZED to verify the sim.

But I won't be cruel and make you think too hard:

1.  Cycle starts at sunk condition.  No payload weight.
2.  Energy is input, work is done to lift a payload weight.
3.  Payload is removed, input energy is removed.
4.  ZED inputs and loads are the same as 1., so ZED settles back into same state as 1.  Cycle is complete.

Ah... you are fiddling here. How is the input energy removed? Isn't it done by draining water AS THE ZED SETTLES, and TO MAKE THE ZED SETTLE? So the second half of step 3 isn't complete until the Zed has indeed settled. Can you or mondrasek or webby actually demonstrate this complete cycle?

You are jumping to some sort of conclusion about about O/U that was not even implied by my test sequence.  Having a prejudice blinds you to what is being presented.  I know all too well... as my wife informs me.

I'm not sure what your wife has to do with this, but...
Yes, you are. No system has demonstrated your steps 1-4. This is a claim, then, about what the data "might" show wrt the performance of a system.
If you DO have a system that actually performs as you HAVE INDEED CLAIMED in your steps 1-4, then why can you not stack up an arbitrarily large "overunity" total lifted amount as I have noted above? There would certainly seem to be nothing to prevent you from starting out with a hundred thousand or even more individual payload weights and move them from the bottom to the top of your lift height, for free, since you are recycling your input energy over and over.

Are you embarrassed by this excess of riches? Is there something wrong with my interpretation of your steps 1-4 and the possibility of raising an arbitrary number of payload weights with the same, cycling, input energy? Please be so kind as to point out exactly where my error is, rather than telling me how my prejudices (which are shared by a bazillion textbooks and PhD physicists, at least) blind me. Please... don't be cruel by making me think too hard. Just.... show me the sausages. Oh... that's right, you have no sausages, just some non-working sims of a sausage machine. Sorry.

[TinselKoala]

While all the brainiacs argue over the lift, how the lift is actually done and what all that means,, lets try something completely different.

For those that interested, lets talk about the other half of the cycle.

Drain, Vent, Recovery, Exhaust, Return and maybe some I have forgotten,, but these are terms used to describe what happens when the fluid inside the ZED reverses its direction and flows out of the ZED.

When I have TBZED setup for a real good lift value, that would be lift mass and stroke or lift length, the value of this fluid coming out of TBZED is interesting.

To start with when I lower the reservoir a little bit maybe a little bit of water comes back,, NOW it must be remembered that the reservoir is way up high in the air, not down on the table top.

So next I lower it a little more and more fluid flows back into the reservoir, but to be honest the amount of fluid that returns when I drop from full lift height to precharge height is not as much as the fluid I used to go the other way, it is less, much less.

So next I lower the reservoir further and this time the lower I move the reservoir the more fluid is coming out, a higher rate of return, so when I finally have the reservoir down to start position I have all the fluid back in it.

My conclusion from doing this many times is that I have close to 50% return from the input,, the input being a straight up lift from point a to point b rapidly and the return being a slow ramp down value.

Thank you, Webby. It is clear from your testing that you don't recover the full input simply by lowering the input reservoir to the "precharge" height, you must go below that to provide a "suck" of sorts. In your description above, though... are you leaving the payload weight on, at the top, or are you removing it, as see3d and mondrasek are describing?
If you are leaving the payload weight on at the top, and you still have to lower the input reservoir below the "precharge" height to recover.... what would happen if you took the payload weight OFF at the top? Would you have to lower the input reservoir still more to recover, or will the Zed settle by itself, as see3d seems to expect?

[TinselKoala]

And... just in passing.... I can't help but note that Yet Another Page has come and gone, without anybody reporting the simple weighing of the actual weight being lifted by the added water input, tested by the simple method I detailed some time ago.

We've gotten qualitative confirmation that this weight is _less_ than the actual dry weight of the moving parts. But by how much? Substantially so, I think, but I don't have an apparatus to test.

If I did have an apparatus, and some brainiac asked me to do a simple test like this, and for some reason I did not comply, and yet went on with an analysis that assumed without justification that I was lifting the whole weight of the moving parts without the assistance of the precharge.... what then would you think of me, I wonder.

[MT]

Been looking through my spreadsheet again with the single, no layers model, ZED that Fletcher and MT were looking at a bit back. I'll post the spreadsheet later again now I've added some checks as Fletcher suggested, but wanted to get some thoughts first.

With the setup the spreadsheet cam with last time, judging by the amount of volume available to pump the water in to in the pod containing tank, the starting PE of the water is 19.8 J (as the tank can be partially filled without the pod floating), and once filled, is PE 123.5 J. This gives us a minimum amount of work required to fill the pod tank as 103.7 J.

Once the pod is let go, the PE of the water drops to 52.3 J (difference of 71.2 J), whilst the pod only gains 56.9 J. As the force on the pod to go up is that of the water being pulled down (I think?), this means our total potential maximum work out could be 71.2 J. Under normal circumstances, I guess the extra would be accounted for and lost from the pod flying out of the water a little way before falling and bobbing about a bit till it found equilibrium.

Then draining the tank back to it's starting position, which cost us nothing as gravity chips in, we could get out the calculated drop in PE of 56.9 J, which we just gained from the pod rising, as the pod falls.

In PE differnce: 103.7 J
Out PE Difference: 71.2 J + 56.9 J = 128.1 J
Net: +24.4 J

Hi AmoLago,
I do not know how other but I could not open your simpleZED file, seems corrupted.
If understand you correctly you are not keeping pod completely submerged during stroke right? Just precharge and then let waters in gap fall.

To you your calculation how I understood it:
You start with some water with PE 19.8J
Pod is locked.
Adding water increases potential to 123.5J

Workin 103.7
Pod workout 56.9J (with no losses 71.2J)

COP of first ZED 56.9 / 103.7 = 46%  (you are saying without losses 71.2 / 103.7 = 68.66%)

PE water left after stroke 52.3J
Since you started with 19.8J your usable exhaust is 52.3 - 19.8 = 32.5J

This exhaust can be used for second ZED.
Now assume adding exhaust on top of initial 19.8J will increase PE of second ZED to 52.3J.
You still need 123.6J - 52.3J = 71.3J to get it fully precharged. First ZED can provide only 56.9J but without losses 71.3 which basically means that all workout of first ZED is needed to finish precharge of second ZED leaving nothing net left.

Yesterday had some time to croscheck my spreadsheet posted in #2174 using neptune's idea of auxiliary tanks. And came to the same conclusion that all workout of first 0layer ZED is needed to finish precharge and stroke of the second leaving nothing left. Again this is just 0-layer system, ZED is using >0 layers. I still need to find out what went wrong in calc in #2174 that showed really robust OU.

respect,
Marcel