Hydro Differential pressure exchange over unity system.

[see3d]

See3d .. I don't know what formula's you are working thru but one comes to mind as a possibility.

That might be for a fluid drag formula to take account of viscosity - a simplified one I might build & use would be say ...

Hi fletcher,

I only wish I was smart enough to be doing fluid dynamics in my simulator. 

My simulator is quite modest as are my capabilities in this type of math.  I am only dealing with a static 2D model in my simulator.  This will actually be a best case simulation of the ZED, as no frictional losses are included.  The worst case senario would be 100% efficient.

The actual problem I am working on has to do with coming up with algorithms that do not require an overly large amount of iteration to find a solution to multiple interacting variables.  I am also not an algebra or calculus genius.  I feel like I am rediscovering all the math and physics principles from the ground up... LOL

I will give you a taste of what I am working on (and it is my last problem to solve).  I start with a single layer, single ZED sunk to the bottom stop and at a low energy state.  I place a too heavy to lift weight on top of the riser, then apply an input force to the piston.  I have worked out pages of formulas that describe the relationships between the water heads, air pressures and volumes, and forces at every point of interest.  I ended up finding it easier to solve the problem using a binary search technique for this first step where the ZED is pressurized, but the riser is not allowed to move.  I increase the internal energy of the ZED until it is producing a back force in the piston equal to the input force applied to the piston.  That puts the ZED into its fully energized state.  It takes about 24 iterations to get an answer to the max precision of my simulator (IEEE 32 bit float).  All the relationships can be reduced to Y = mX + b form.  If I wanted to put more effort into it, I could probably figure out a quadratic form to make it a single pass.  So much for the easy stuff.

Next, I want to allow the riser to move up a specified amount and rebalance all the internal relationships.  This is the tricky part.  When I move the riser up, it affects everything.  There is no one thing that stays as a constant (except the input force which is non-linear to the rest once the riser moves).  With no single known internal variable to work from to calculate the others from, I am stuck with iterating in a circle until the system is settled.  Then after I am in a settled known state with the riser in a fixed position, I can then do a binary search like before to get the internal state to match the input force again.

So I am working on getting the kinks out of my math and doing many internal relationship calculations for internal consistency checks for verification.  I understand what I want to do, it is only getting from the dynamic geometry I can see in my mind to a formula and algorithm in the simulator that is slow going for me. 

[fletcher]

Dennis .. I can't offer too many sage words of advice because every sim is built from the ground up & you have to know the package & the constraints intimately - sometimes I make quick & dirty force approximations of something i.e. sacrifice some accuracy for expediency or function, if its not a show stopper or has minimal influence on outcomes - later in the run testing stage I debug it if needed or upgrade the formula(s) for more realism etc.

In your case it sounds like you have accounted for the major constituents of Inputs & Outputs - it should be good enough to give a fair representation of what happens in a single ZED cycle - that's when any advantage in sim world should show thru or not - if it does then accuracy can be retro-ed into the sim etc.

I should add that I am mighty glad it is you building this sim from the ground up & not me, LOL.

I just get to sit back & puff on my wisdom pipe from time to time [all care & no responsibility] while you do all the hard work 

[AmoLago]

Hi AmoLago,

Yes, as the piston goes up, it raises the head around the pod, which increases the output force.  When the riser hits the top stop, it can not rise any further.  However, if the piston continues to rise, the water head around the pod continues to rise and increases the pressure against the top stop.  The actual physical location of the riser should never go down as the piston is going up.

Hi See3d,

Thanks for indulging me. I know this isn't a forum for beginners as such, but I'm just really interested and want to be involved (if I can!)

I can see that if the pod/riser is locked or hits the top, then any force applied by the piston will raise the head. This is why I looked mostly at video 3 (that's ZED_1_Layer_Spring1, just in case they're ever displayed in a a different order for some reason!?), which doesn't appear to have any locking or "topping out".

So from your explanation, was my original assertion correct then?

The ability of the piston to raise the Head around the pod/riser in the main chamber (or from another point of view, the apparent decreasing buoyancy force of the water applied to the pod/riser), must come from the decreasing buoyancy force / increasing gravitational force being applied to the "wings" of the pod/riser in the H1/H2 chamber as the "wings" are being lifted out of the water.

Because the "wings" are being lifted out of the water,  the whole pod/riser no longer has the equilibrium of the gravitational and buoyancy forces applied to it and so slowly sinks to back that equilibrium, as is shown by the pod/riser sinking, or conversely as the piston raising the head.

Amo

[see3d]

Hi See3d,

Thanks for indulging me. I know this isn't a forum for beginners as such, but I'm just really interested and want to be involved (if I can!)

I can see that if the pod/riser is locked or hits the top, then any force applied by the piston will raise the head. This is why I looked mostly at video 3 (that's ZED_1_Layer_Spring1, just in case they're ever displayed in a a different order for some reason!?), which doesn't appear to have any locking or "topping out".

So from your explanation, was my original assertion correct then?

The ability of the piston to raise the Head around the pod/riser in the main chamber (or from another point of view, the apparent decreasing buoyancy force of the water applied to the pod/riser), must come from the decreasing buoyancy force / increasing gravitational force being applied to the "wings" of the pod/riser in the H1/H2 chamber as the "wings" are being lifted out of the water.

Because the "wings" are being lifted out of the water,  the whole pod/riser no longer has the equilibrium of the gravitational and buoyancy forces applied to it and so slowly sinks to back that equilibrium, as is shown by the pod/riser sinking, or conversely as the piston raising the head.

Amo

You might not understand what the "spring" video is showing.  It starts with the ZED fully energized with an input force and up against the top stop.  Then it shows what things look like if you put your hand on top of the ZED riser and force it down to the bottom stop.  The input force is still applied all the time.  So the transfer function is just showing how stiff and linear the "spring" force is.

I would not spend a lot of time with the old videos though.  The will have to all be revised as I discovered some errors in the simulation that I have been working on correcting.  Of course, the errors resulted in the entire system being one order higher function than I originally thought it was, so the formulas got much more complicated.

I think I have made some good progress tonight in getting it figured out -- just have to look for a few clerical errors in the formulas now.  :-)

[AmoLago]

You might not understand what the "spring" video is showing.  It starts with the ZED fully energized with an input force and up against the top stop.  Then it shows what things look like if you put your hand on top of the ZED riser and force it down to the bottom stop.  The input force is still applied all the time.  So the transfer function is just showing how stiff and linear the "spring" force is.

I would not spend a lot of time with the old videos though.  The will have to all be revised as I discovered some errors in the simulation that I have been working on correcting.  Of course, the errors resulted in the entire system being one order higher function than I originally thought it was, so the formulas got much more complicated.

I think I have made some good progress tonight in getting it figured out -- just have to look for a few clerical errors in the formulas now.  :-)

Hi See3d,

Awesome, thanks.

Can't wait for the new stuff.

Amo