Feature request: ability to visualize waterline, CoB and CoG

[martijn-heil]

As per title, I think a useful feature for hull design would be the ability to visualize the actual waterline, center of buoyancy and center of gravity of a ship given the weights defined in this workbench.

[sanguinariojoe]

I am coming with something soon!

[martijn-heil]

As an additional note I think it would be very useful if you could do this with angles of heel too, so for example you can visualize the waterline of a heeled-over sailboat. Especially with modern hull design trends with hard chines and wide beam this is important to see when choosing their placement on the hull.

[sanguinariojoe]

Hey Martijn!

Check this out: #23

I added a new tool called Sink and trim, which is computing the equilibrium point on top of a load condition. You can show the results in the ship upright position, or using the free-surface as the reference (i.e. the free surface is the z=0 plane).

I am merging it right now, so you can test it with the addon manager. Let me know!

P.S. Some changes I made might broke some other tools, so if you test all the tools I will really appreciate that

[martijn-heil]

Thanks for the quick work, I'll take a look!

[martijn-heil]

Maybe I'm just doing something stupid, but it looks as if the COG of the hull isn't calculated correctly.
I've got a very simplistic scow-bowed hull shape that I'm trying it on, with a cut out in the back that's meant to resemble some kind of large open cockpit.
I've defined a single weight (the assumed weight of the structure) at the default location it places the weight (the centre).
Subsequently I've executed the Sink and trim tool with 'Reference on the free surface', which leaves me with this result;

Simply looking at it by eye, it seems like the COG is too far aft.
Further investigation by calculating and illustrating the actual COG of the resulting SinkAndTrim_Ship body using the FCInfo macro reveals the actual COG at the centre of the crosses:

Which appears to confirm that indeed the COG calculated by Sink and trim is too far aft.

This could explain the rather unnatural looking trim that my simplistic hull shape has attained.

Location of the single weight (note that it is in front of the cockpit)
(it may seem a little off-center in this screenshot but I can assure you that it is in fact located at the transversal center):

Some more pictures to clarify further the hull shape:

[sanguinariojoe]

github automatically closed the issue...

So, as far as I understood you have created the weight selecting the ship itself and executing the tool. Thus you expect your COG is in the COG of your volume, right?

Confirm me that so I start debugging it (you may also attach your FreeCAD project if you want)

P.S. This might be wrong, since FreeCAD devs have introduced Units all along the code, which is so far breaking this module. I'll be fixing these kind of bugs for a long time :-p

[martijn-heil]

So, as far as I understood you have created the weight selecting the ship itself and executing the tool. Thus you expect your COG is in the COG of your volume, right?

That is correct.
Here's my project if you want to take a look:
project.zip

The weight also doesn't have a weight symbol like those in the wiki, instead the weight visualizes as a copy of the hull, but that's mostly a cosmetic annoyance.

[martijn-heil]

I also have a suspicion that the entered weight in kilogram is treated as a much heavier weight off by a power of 10, like 100 kg is treated as 1000 kg. This needs to be tested further to be confirmed though.

Furthermore, after doing a Sink and trim the results also include some text which contains:
Δ = 1.80 t
Maybe it is a naval architecture thing, I'm a programmer, not a properly trained naval architect, but what does it mean?
It seems to me that it's the displacement, but that doesn't make sense because I get this displacement with a single weight of 100 kg (100 kg!, not 1000!).
When I measure the actual displacement of the underwaterbody again with FcInfo it is indeed very close to 1.8 metric tons.
Is there some kind of hidden intrinsic weight attached to the ship that I can't see anywhere?

On the wiki in the second part of the Freecad ship tutorial it says:

Weights definition tool can be used to set first category of weights. When you launch the tool for first time (with ship instance selected), the Ship workbench initializes ship weights with Lightweight ship (equal to ship displacement) that is placed on the ship geometry center of gravity X coordinate, and at design draft height.

I haven't seen this behaviour, I guess the wiki tutorial is here slightly out of date?

Retrying the Sink and trim with the weight set at 400 kg and the weight manually moved to the actual lateral COG (X axis) as indicated by FcInfo I get a Δ = 7.20 t. The trim still looks unnatural and the SinkAndTrim_COG is still too far aft, somewhere in the cockpit, even after moving the single defined weight forward a lot by hand.

[sanguinariojoe]

Ok, I will take a look, don't worry!

I also have a suspicion that the entered weight in kilogram is treated as a much heavier weight off by a power of 10, like 100 kg is treated as 1000 kg. This needs to be tested further to be confirmed though.

It sounds like a gravity doing funny things.

but what does it mean?

Yes, Δ is the displacement, which yes, shall be equal to the weight

On the wiki in the second part of the Freecad ship tutorial it says:

Yeah, the wiki is outdated, forget about it for the time being. See #15

[martijn-heil]

As a side note, I haven't calculated it by hand so far, but simply looking at it by eye I think the proper natural trim of this simplistic hull shape will be bow-down, considering the lack of buoyancy at the bow and the lack of weight due to the cockpit cutout in the back. I definitely doubt that it will have 0 degrees trim, which is why it makes a nice test case for this feature.

[sanguinariojoe]

Well, I am pretty sure this is a problem of lack of documentation rather than a bug...

I have downloaded your project, removed the load condition as well as the weight, selected the ship, executed the weight creation tool, set a density of 300 kg/m3, and executed the sink and trim tool:

I suspect you created your weight, and then selected and edited it in the data tab, removing the density and setting the mass. Am I right? Another possibility is that you just simply set the quantity in kg instead of kg/m3. Whatever way you did so, you are instructing FreeCAD-Ship to consider a punctual weight, so it will compute the COG as the average of the shape vertices. Actually the user should never manipulate the weights in the data tab.

Let me know if you hacked the weight on the data panel or you did that in the input box please

[martijn-heil]

Right.. I've been doing some of my own debugging, including reading lot's of your code, and now I got a correct result.

I read in the wiki (outdated, I know):

Weights definition tool can be used to set first category of weights. When you launch the tool for first time (with ship instance selected), the Ship workbench initializes ship weights with Lightweight ship (equal to ship displacement) that is placed on the ship geometry center of gravity X coordinate, and at design draft height.

So that's what I did. However when you do that with the current version of the workbench, it turns out you simply create a volumetric weight instead of a point weight, a volumetric weight with the shape of the hull. This explains the 'copy of the hull' thing that I had going on.
You can still enter a mass in kilograms for a volumetric weight, even though that doesn't make any sense as it's supposed to have a mass per unit instead of an absolute weight. It never complains anywhere about the fact that the 'Mass' field has a value in kilograms in it, so it seemed like it was all correct.

I got it working now by creating a vertex on the COG of the hull using the FCInfo macro and having that selected while creating the weight, which, turns out, creates a point weight! This is what I expected to happen in the first place, I didn't expect any volumetric weights, but that's mostly due to being misguided by the outdated wiki I guess.

This point weight you can assign the mass of in kilogram in the same way as I tried to do with the volumetric weight I had before, but now with a point weight it does make sense and works as expected.
Executing the Sink and trim tool now results in this very plausible-looking trim:

So basically this was all down to a misunderstanding of how to create the weights properly. Proper documentation will solve this issue I think.

Then we come to the second, kind of unrelated to Sink and Trim, problem: the COG on volumetric weights being seemingly miscalculated.
This remains a problem, the COG calculated on a volumetric weight does not correspond to the COG calculated on that same object by FCInfo. Looking at such an object by eye and using common sense it would seem that FCInfo is correct and FreeCAD Ship is wrong on this COG.

In my debugging I have traced this seemingly wrongly calculated COG back to the weights_cog function, the result that this function returns is already wrong when volumetric weights are involved, so if the COG is indeed wrong as suspected, the cause should be hidden somewhere in that function or any other functions it subsequently calls to calculate the COG. This way I have ruled out that the COG only gets misplaced when displaying it to the user.

The weights_cog function behaves correctly when a single point weight is involved.

[sanguinariojoe]

You can still enter a mass in kilograms for a volumetric weight, even though that doesn't make any sense as it's supposed to have a mass per unit instead of an absolute weight. It never complains anywhere about the fact that the 'Mass' field has a value in kilograms in it, so it seemed like it was all correct.

Yeah, I am investigating the API, but it is not straightforward to handle those "special" FreeCAD input fields. I suppose I am discovering the trick sooner or later.

Proper documentation will solve this issue I think.

It will come!

Then we come to the second, kind of unrelated to Sink and Trim, problem: the COG on volumetric weights being seemingly miscalculated.

I checked right now with your example and the COG is perfectly computed up to the machine precision. I typed this on the Python console to get the COG:

obj = App.ActiveDocument.getObject('SinkAndTrim_Ship')
solid = obj.Shape.Solids[0]
solid.CenterOfMass

The result was Vector (217.19599201010172, 4.708195249192291e-13, 15.89025758032426). Then I typed this to get the COG point:

obj = App.ActiveDocument.getObject('SinkAndTrim_COG')
v = obj.Shape.Vertexes[0]
v.Point

The result was Vector (217.19599201010192, 4.882583135311156e-13, 15.890257580324487)

Let me know please!

[martijn-heil]

Let me know if you hacked the weight on the data panel or you did that in the input box please

Indeed I tried to in a few instances, it's not really clear you shouldn't, but I understand your difficulty.

I suspect you created your weight, and then selected and edited it in the data tab, removing the density and setting the mass. Am I right? Another possibility is that you just simply set the quantity in kg instead of kg/m3. Whatever way you did so, you are instructing FreeCAD-Ship to consider a punctual weight, so it will compute the COG as the average of the shape vertices. Actually the user should never manipulate the weights in the data tab.

I did both on at least a few occasions trying to figure out how the tool works.

I downloaded my own example, opened it in FreeCAD and first thing I did was run your example code, but I get these results:

>>> obj = App.ActiveDocument.getObject('SinkAndTrim_Ship')
>>> solid = obj.Shape.Solids[0]
>>> solid.CenterOfMass
Vector (211.89871559507546, 5.362912640940787e-13, 73.60471564656541)
>>> obj = App.ActiveDocument.getObject('SinkAndTrim_COG')
>>> v = obj.Shape.Vertexes[0]
>>> v.Point
Vector (-1435.4830122781696, 8.28e-13, 219.37021067447063)

This can be explained by your remark:

Whatever way you did so, you are instructing FreeCAD-Ship to consider a punctual weight, so it will compute the COG as the average of the shape vertices.

Retrying it your way, by setting a density of 300 kg/m3 indeed gives the same results as you have.

Now I just have a simple question;
In the initial feature request I mentioned being able to execute this tool for a heeled-over ship. You added the ability to calculate it in reference to the free surface which I think is supposed to be used for this function, right?
How would I go about using Sink and trim with a heeled ship? How do I make the ship heel? Do I need to rotate the ship itself or do I need to define a rotated Z=0 plane below it? And if the latter, does it matter how close it is to the hull or can it just be at any place in the vertical space?

[sanguinariojoe]

If your ship is designed with a heel angle, you just need to get the solid rotated before executing the ship creation tool:

P.S. Do not create the ship and then rotate it, it might not properly work (or maybe yes...)

[martijn-heil]

P.S. Do not create the ship and then rotate it, it might not properly work (or maybe yes...)

No that doesn't work indeed, I already tried that haha.

I've got it working I think, a bit tedious, but it looks great!

One thing I would like to add though, everytime I immediately change the opacity of the generated free surface to 0, so that it isn't seethrough. This makes the visualization a lot clearer in my opinion.

[sanguinariojoe]

One thing I would like to add though, everytime I immediately change the opacity of the generated free surface to 0, so that it isn't seethrough. This makes the visualization a lot clearer in my opinion.

Ok! I am making it opaque in the next commit.

Feel free to open another issue about the weights creation and the units

[sanguinariojoe]

Hey @martijn-heil , as you can see I have changed the way the user may introduce inputs, in such a way different units can be used, but they should be compatible with the expected value. This way, it is not possible to set the weight in kg for volumes anymore.

I suppose that is finally fixing this issue! Please, check and feel free to open new issues if you find more errors