water ballast hull form

Terry's thread on water ballast has got me digging out old stuff and I took another look at a piece of code I wrote to solve for the hull shape that has the highest righting moment at the instance of flooding for a given perimeter. All ballast is fixed in bottom and has density of one. Program solves shape and ballast amount simultaneously.

bug fixed, see post 13



The shape of the hulls I get is a bit counter intuitive, but it certainly looks like plenty of real world hull shapes. The hollow bilges are odd considering I was trying to minimise perimeter, but I think I've got my head around that one now.

Looking for any flak or corroboration on the shapes.

 

Very interesting. Some questions:
- Is this 3D hull shape or 2D section shape?
- Why constrain the perimeter?
- Round sides, no chines only considered?
- Is depth constrained?
- What do you think drives the hollow bilges? My guess is a depth constraint, hence the question above.

My guess is if beam is constrained but nothing else the sectional shape with water ballast which would have the greatest righting moment would be a rectangle. Depth of rectangle and resulting amount of ballast would depend on the heel angle chosen for optimization.

 

Hi DCockey,

The form is broken into 20 horizontal slices, with the offsets pushed around by the solver. A random dither serves as an additive bump function, and a tiny amount is subtracted from all stations each iteration to keep the ball rolling. Once the bump is applied, a new chine to chine perimeter is calculated and new moments and the old and new are compared after dividing by the perimeter cubed. I wrote a prog that did a flat bottom one chine hull, and one that did a vee bottom one chine hull as well, solving for one or two angles and the relative panel lengths.

so, just 2D, and the depth fixed at twenty, with a center keel point at 0,0 and offsets running from 0 to 20 inclusive.

As far as the hollow bilges are concerned, I think that with the heeled CB above the CG, the hollows mostly serve to optimize the tilt angle from CB to CG. If the hollows were filled in, the CG would lower, but the CB would lower even more because it is farther away, reducing both the angle and distance to the CG. The added mass associated with the extra included area cancels the horizontal change in CB position, but not the vertical change.

For what it's worth, Michlet will produce a similar shape if beam is constrained and KM? (can't remember the stability criteria in Michlet) has a large lower bound. That's a parametric shape, but still is quite similar. At first I thought it was an artifact of Michlet's solver and used to fight it, but it seems to be the real deal. It also explains in large part why a single chine hull has the potential to be as good as it is. If you create an equal volume single chine hull the actual offsets do not vary by as much as you would think.

 

Thanks.

From the first post:

What determines the amount of ballast?

Is the CG height of the water ballast dependent on both the amount of ballast and the shape?

Is there anything which drives rounding of the shape, either explicit or implicit?

 

Ballast is that which matches the volume of the submerged heeled hull. The CG is figured as if water ballast is sitting in the bottom of the hull at no heel.

The offset table starts at the port chine and reads around the hull. Excel calculates area and moments for every polygon, each beginning at port chine which is submerged and advancing around hull. So I have a table of areas and moments beginning with the hull out of water with the port chine touching and then rolling the hull section into the water pivoting on the port chine.

The heeled waterline is calculated (heel angle is a user input at present, but can be set to dither or optimise on its own) and the polygon that is biggest, but smaller than the heeled area is picked (offset is below waterline test). The intercept of the waterline and next hull segment is calculated and the additional bit of area is factored in, along with its moments. The prog then takes this area and solves the nonheeled case starting at the keel and working up. The last bit is interpolated as before. The only cheat is that I use the same CG for both the original and the bumped hull, but the difference is so tiny once convergence has begun that it doesn't matter. It can matter at startup. It is possible to choose a starting hull that will not converge because of this. Extremely low beam hulls can start badly. A B/T of 1/3 starts fine.

I should go back and rewrite the whole code using array notation in Excel. Would save a lot of comp time. I'm also doing a lot of unnecessary calcs with area. it gets divided out then multiplied back in for centroid and moment calcs, but I wanted real numbers for these variables, not just the most efficient routine.

 

D-

One other thing. The earlier version did not have a calculated CG vertical location. It used a simple assumed (fixed) position and did not generate hollow bilges.

 

That seems to imply displacement is 100% water ballast. I expect the results would vary with ballast ratio.

Why not update CG height during iterations? Have you varified the results are independent initial shape and CG height, provided the there is convergence?

 

Yes, the Cg is correct for each iteration, and convergence is very good. I can start with hulls optimised at greater and lesser heels and end up at the same place. Spent a good bit of time checking for engine artifacts in the solution by fiddling with the bump function (which is- add a little to all the offsets above the selected offset of new hull and subtract a tiny amount from the offsets of the previous hull and compare normalized RMs). The offset chosen to be bumped is selected by a modified random process. The size of the bump is fixed as a percentage of max beam. It could be improved upon. I could track the success rate of bumps at each offset using a decay function and shape the selection based on the ranked success rate. You're right to challenge this stuff though- I found a whole bunch of pitfalls when I tried some stuff to speed up the process such as varying the size of the bump. Its important to keep the bump size bigger that the total of all the subtractions. Sounds obvious, but it can get lost easily. I thought I would vary the bump size based on the distance of (Offset N+2 - Offset N-2), but that failled for several different reasons. Tumblehome being one of them.

It's still very much crap code. Could be made to run 100 times faster with a little work.

Since you asked about chines-

 

What's the rationale for the maximize righting moment / perimeter - maximize righting moment / wetted surface area? How about righting moment / displacement?

Are you using upright or heeled perimeter?

 

Well, you have to normalize the two comparison hulls in some manner that is dimensionally correct. I could use any number of things. Beam max cubed is probably the most obvious alternative, or hull section area ^ 3/2. I thought perimeter from chine to chine related to shell cost nicely. Could include a deck shape for a rotomolded sit on top kayak as well. That would relate to cost of production since most resorts that rent these things want a stable boat that can handle a 300+ pounder and will buy the cheapest one.

One thing about the way I have set up the comparison is that I can fiddle with the comparison criteria and weightings easily since I took the time to calculate many properties for each hull. Wetted distance is an obvious item of interest and could be given weight in the selection to the extent that a sail is generating the heeling force to create propulsion. I have in the back of my mind the Florida Challenge boats with the 10sqft sail limit. What would an offshore 10sqft sailboat that can take 45 knot winds look like? what VMG to windward w/ and w/o paddle or pedalprop assist.

 

I'm still confused about you "ballast" assumption. It seems like you are assuming water ballast equal to 100% of displacment, without any allowance for the structure, rig, occupants, etc. Is that correct?

Any references on the "bump" method of solution. Quite a while ago I did a lot with solution of sets of equations, both linear and non-linear but haven't heard of that term before.

 

yes, Its just an exercise at the moment. I'm still quite suspicious about the code, but haven't had time to work on it for the past couple days. That bit about getting my head around the idea of the hollows- well I'm doubting that again. I'm going to try to force a flat bilged hull and compare directly. Just need to delete several offsets near the keel. I tried to remain concious of the order that the spreadsheet calculates cells, But it is possible that a difference between port and starboard is accruing. Need to test more against know solutions.

 

-from my post #5 -

Well guess what- It does matter. It created a bias where all new hulls would have a higher CG than they should have relative to the old one, and the bias slowly accumulated. With separate CG calc for unheeled condition in both hulls I get a much better result-

 

The revised results look good.

Where are the upright waterlines?

 

Will add next go round. Just changed out the bump function and now run a symmetrical bump function that can push in or pull out a set of stations above the chosen one. This solves the tumblehome problem and guarantees there are no artifacts from the bump function. Bump size diminishes with time and runs are pretty quick now.

Happiness is an efficient proggy.