yes - here with all the torque stuff commented out
buoyancy_archimedes3.gh (59.7 KB)
Though really for this 1d problem a simpler root finding without Kangaroo would be sufficient.
1 Like
Hah! Awesome. Will certainly be trying both methods as the roll/pitch (âtorque stuffâ) is very nice.
Since boat hulls are not boxes, or otherwise simple shapes, it wasnât obvious to me at all years ago.
P.S. I understand the idea of âvanilla GH brute force samplingâ (though your code doesnât work without MeshEdit plugin) but accuracy is very important, which means small increments which means SLOW. What would be cool is a Boolean toggle input on the Buoyancy goal to disable/enable the âtorque stuffâ that you commented out.
As mentioned above - the volume component in that previous definition can be swapped directly for the native GH one - no plugins needed.
By root finding though I meant making a simple script which is neither the brute-force sampling method or Kangaroo. I think this would be fastest and simplest.
I tried that but failed - wasnât sure if you were using volume or centroid, but it doesnât matter.
I donât know what you mean?
I modified your script to test either Bear or Boat (cyan group) using âtorque stuffâ or not. Works fine with the bear but the boat sinks off the bottom of the screen. Is it a bad mesh? Or because the boat CG is not inside the hull? (two hulls)
buoyancy_archimedes_2023Mar10a.gh (184.4 KB)
Or maybe a units problem? Checking⌠Yeah, I can sink the bear too if I increase its weight. 
Or float the boat if I drastically reduce its weight. Off by ~100 somewhere?
As a check, look at weight/volume to make sure your object isnât denser than the liquid itâs floating in.
Iâll try and make a root finding script example.
Iâve been using variations of this boat for years. Length is in feet (~70 feet), displacement is pounds (21705 pounds.) Iâm sure the scale is off somewhere.
Weight appears to be off by exactly a factor of 100.
Sea water weighs 63.926 pounds per cubic foot so this boat should float.
P.S. The boat is sitting on its designed waterline, the âWorld XYâ plane. Sorry to be dense about this.
The rest of the definition is set up assuming all metric, so the model dimensions are in m
Also - it looks like the lbs to kg conversion is inverted in your last definition.
Does that mean I have to scale my hull up to use this? Doing that and fixing lbs to kg conversion certainly looks more correct, but Iâm concerned about what that means for the values returned and for orienting the original brep? It looks like the boat is raised slightly, though the scale is confusing me about how much? Inches definitely matter! ~1500 PPI (Pounds Per Inch immersion) in this case. I set the âSpecific gravity of fluidâ to 1.026 for seawater but is there more to it?
Using the âNo Torqueâ option is stable but the default âtorque stuffâ is definitely not.
buoyancy_archimedes_2023Mar10b.gh (186.0 KB)
By the way, the torque stuff is definitely interesting for conventional boats that are not symmetrical end-to-end like this one. The CG for this boat (most boats?) is not at the center of volume either, but that is easily specified in this model.
Iâm sorry Daniel, this has become as embarrassing and frustrating for me as it must be annoying to you.
Iâve been utterly lost in scaling errors, trying to understand differences between what this model is showing vs. what I know to be true. That includes draft and COG, which of course rolls with the boat⌠By other means, I believe the COG is at X=0, Y=7.913 feet and Z=~5 feet.
Precision is critical for boats, which is one reason Iâve always preferred NURBS to mesh surfaces. Can I get that from Kangaroo?
For this kind of boat (a Pacific proa that always keeps the smaller hull to windward), itâs very important to get the âNo Torqueâ solution because thatâs where it starts to gain stability (righting moment) when the leeward âpodâ dips into the water - around 35 degrees of heel.
Corrected the feet to meters conversion so the boat gets smaller and sinks again. 
What makes this model metric? Can that be avoided and use imperial units somehow?
buoyancy_archimedes_2023Mar10c.gh (316.2 KB)
I might be completely wrong here, but wouldnât it be more reliable to import the entire thing into a metric rhino file? Havenât tested anything, just a thought.
That wonât fit my work flow. I donât think Rhino units have any effect at all on these numbers. Iâm not used to thinking metric, especially boat displacement in liters instead of cubic feet, but Iâm beginning to understand - sort of.
There are 28.31685 liters per cubic foot. So if my static displacement is 21704.834393 pounds and seawater weighs 63.926 pounds per cubic foot, then my displacement is 339.53062 cubic feet or 9614.437628 liters. My conversion using Kg per Pound says 9845.21436 kg, which is a difference of 1.024. Very close to the âSpecific gravity of fluidâ slider I set to 1.026, so I suppose it accounts for that?
The weight of seawater per liter is 1.03kg.
Sigh. This doesnât clearly address the issue of how to scale my boat. I donât even know which point I should use as center for scaling? The origin? Or the COB? (Center Of Buoyancy)
By trial and error, I find that if I scale my boat by a factor of 3.0825 using the origin, it floats at the expected position. But this is all too loosey-goosey for me. My Anemone solver is cumbersome to use but I have a very high degree of confidence in its results. Not so yet with Danielâs cool model.
The total volume of the boat/bear are irrelevant. Their weight and size/shape determines what volume of seawater is displaced below the waterline.
I was thinking that maybe instead of scaling my geometry I should fudge the weightâŚ? So by trial and error, I multiplied my displacement in pounds by a factor of 0.015500 to get the unscaled boat to float on its lines. Then realized the result was very close to the cubic feet displacement I mentioned, 339.53. So I used that instead and low and behold, itâs on the money!!
I donât know why yet? But if it makes sense, maybe this is the solution?
buoyancy_archimedes_2023Mar10d.gh (310.5 KB)
The COG position still needs work, especially rotating it with the hull - as @Ben_Harker suggested.
P.S. I broke the bear in this code but will fix it in the morning, along with a more accurate COG for the boat, âNormalâ and âRolledâ. When the torque solver is used, that COG for the rolled boat needs to move with the boat.
As to why cubic feet displacement works, Iâll leave that to Daniel but it makes sense as a measure of displacement by volume, appropriate for the boatâs dimensions in imperial units, eh?
P.P.S. Using the default Buoyancy goal (with torque), it looks like the boat pitches for no good reason and finally settles with one end higher than the other, which shouldnât happen.
Iâve integrated the Kangaroo model (unchanged) with my old Hydrostatics code. (work in progress)
MAJOR CONTROLS
- âMODELâ selection, cyan blob at top
- âBear | Boatâ selection and âReset Solverâ, cyan group at the bottom
- âData Damâ after solver, red group
There is an abbreviated copy of the Hydrostatics code after the Kangaroo Solver, protected by a Data Dam. It has a âDifferenceâ text panel that compares the displaced volume before and after the solver. Appears to be 1.01 or less, which is 1% ? Thatâs 3.6 cubic feet or 231 pounds in this case, which is not quite as accurate as I would like but itâs in the ball park. Better when the boat is rolled. âNo Torqueâ solver remains unstable. Both solvers run for a long time.
Not sure what I can do to improve accuracy? Improve the mesh? Adjust âThresholdâ, âToleranceâ, âDampingâ and/or âIterationsâ ?
Hydrostatics_2023Mar11a.gh (263.6 KB)
1 Like
Hard topic, I hope you find the solution 
The only thing I just saw right now is that the mesh coming out seems to have pretty big triangles, which COULD lead to a volume difference of about 1%. update: Just quickly baked the volume from Brep and the converted mesh from your last script and the volumes are already about 0.5% off before you make any calculations (that I donât understand bc Iâm not in the boat business at all) I guess this is why you prefer working with NURBS. Iâd try and improve the mesh, even if this means heating up the room with your pc, but just to know if this causes the deviation after calculations.
But I think you should stick to your nurbs solution if it works fine, kangaroo is a optimizer, not exactly for precise calculations of this kind I think.
B
I think so too. I messed around with finer meshes but didnât see any improvement in precision. It only got slower and slower to the point of being useless. My old Anemone loop is accurate to any number of decimal places (default 3), so it is very precise indeed!
Iâm looking at updating the Anemone loop, perhaps using âFastâ components but wow, itâs complex with two nested loops that search an arbitrary domain, written with the flexibility to solve a variety of similar search problems. I may give up on that now and focus only on floating the rolled/pitched boat.
1 Like
This isnât really correct - Optimisation can give you answers as precise as needed (within the limits of floating point precision), provided everything is set up correctly.
To go back to my earlier point about root finding though - using Kangaroo here feels like a bit of a sledgehammer to crack a nut.
The original question is essentially a 1 dimensional search where we have a single scalar valued parameter to optimise for a single scalar output. So a root-finding algorithm is whatâs needed.
Whatâs more, we know the plane must lie somewhere between the top and bottom of the solid, so we can use bracketing methods which can be very efficient.
The simplest of these is bisection, where you chop the search domain in half each time. For faster convergence we can use various types of interpolation instead of just halving it.
I made an example trying both Bisection and Brent-Dekker root finding:
volumeportion_rootfind.gh (57.0 KB)
Here you can see it finds the plane height to split a shape at to give an accurate volume in a few ms.
(I think this same root finding code could come in handy anywhere you have this sort of optimisation of a single value where the root lies between known bounds. Just replace the âSliceVolumeâ class here with the thing you want to optimise for)
7 Likes
Thanks for the clearification. I am still learning about kangaroo, which I admit is pretty complex and I still lack of much university math knowledge. I figuered it is mostly used for cases, where many constrains come together and a perfect solution is not necessarily possible. I didnât feel this would be the case here for the boat question.
btw, I admire your work and am very impressed of your level of knowledge about meshes and computional geometry. The more I dig into kangaroo, the more I am impressed⌠
Thanks - and youâre quite right about Kangaroo being mainly intended for more complex problems with many variables and where an algebraic or closed form solution isnât possible.
Whenever thereâs a direct and non-iterative method available it is generally preferable to use that over a numerical method, because then we donât have to think about convergence or accuracy.
This problem of finding the plane height for splitting any solid with a given volume doesnât have a closed form solution, so we canât avoid using some sort of numerical method here, but because itâs a single variable this can be a simpler method with guaranteed convergence.
2 Likes
WOW!
This is EXTREMELY IMPRESSIVE! Big thank you, Daniel (@DanielPiker).
Itâs been a very long time since I did a âbinary searchâ in a conventional language. I tried with Anemone over the weekend and failed - many times.
This is a game changer. I replaced Kangaroo with this C# code at the bottom (green group). Iâll be studying this C# code with interest. I see you are using the âBrentâDekker methodâ and have commented out the âsimple bisection methodâ. Wow. So cool. 
Thank you, thank you!
Hydrostatics_2023Mar13a.gh (217.2 KB)
P.S. Itâs so fast that I removed the Data Dam, though might refine that further.
1 Like
I found a mysterious error when setting the roll angle to 55 degrees. Above or below that is fine.
error: Object reference not set to an instance of an object. (line: 101)