SimScale CAE Forum

Collaborative simulation project? Multiphase flow around a boat hull


Awesome, congrats @sjoshi looks really nice! Do you have the total X force ? Does it converge at the end of the run?
I still don’t understand if the boat is freely floating and triming in your simulation, or is in a fixed position at a certain Z value?



I still don’t understand if the boat is freely floating and triming in your simulation, or is in a fixed position at a certain Z value?

Thanks, I forgot to mention this fact: the boat is fixed in space. As you recommended, the water level is assigned such that it submerges the boat upto the point of inflection at the bow.

Do you have the total X force ? Does it converge at the end of the run?

Here are drag, lift and variable convergence plots:




Even though the variables seem to converge in the convergence plots, the drag and lift seem to create a pattern that repeats itself over time. Could this be due to the fact that the boat is fixed in space?

Also, as @Maciek requested, here are the pressure and velocity slices at the center-plane:


Hi @sjoshi,

Your results for drag and lift do not look right. I would expect parameters to ramp up to a steady state value.

I’m not familiar with fluid simulation but this problem looks analogous to a solids simulation where the friction penalty coefficient or penetration penalty coefficient is too high. This causes instability over time (in the case of friction, slip and grip or in the case of penetration, bounce). The results look just like this i.e. the solution converges at each time step but the forces are not stable over time. Also, the instability tends to overestimate the forces. The solution in a solids simulation is to keep reducing the magnitude of the penalty coefficient until the solution becomes stable.

The fact that the solution has converged just means that the internal and external forces are balanced at each time step. If the forces oscillate over time the solver simply finds a solution to balance the oscillating forces.

Many years ago I did some testing to measure boat drag. We towed the measured vessel with another vessel using a tow line with a load cell. I remember that the drag force was consistent over time, for a given speed.

As a rough guide you may be able to estimate the drag force with Dave Gerr’s formula.

LWL = 22 ft (water line length)
v = 3.9 kts (velocity)
m = 7000 lb (displacement, just a guess)

The speed length ratio is:
SLR = v/(LWL)^0.5
SLR = 3.9 / (22)^0.5
SLR = 0.831

The required shaft horse power is:
SHP = m /((2.3 - SLR)*8.11)^3
SHP = 7000 /((2.3 - 0.831)*8.11)^3
SHP = 4.14 hp (3080W)

Assuming a propeller efficiency of 55% the drag power is
P_drag = SHP * 0.55
P_drag = 3080 * 0.55
P_drag = 1694 W

Therefore the drag force at 2 m/s is:
F_drag = P_drag / v
F_drag = 1694 / 2
F_drag = 847 N


O, now positioning looks much better to me.

Also @quequen let’s don’t push it too much at this stage :slight_smile: Personally I prefer step by step approach. To me it was obvious from the very beginning the model is firmly set in its position. I get your point in terms of tilt (heel?), draught etc. but let’s solve one thing at the time.

Adding tilt is not a problem with cut-cell mesh. Releasing some degrees of freedom may be problematic. In longer term however, yes – definitely. But now, I’d like to see full convergence and full control of the free surface.

You know what @sjoshi? I also experienced this strange issue at the inlet you had. But in my case I created my domain in CAD program, then cut the inlet surface into two surfaces so that I could later on define them as air and water inlets and only then exported and meshed.

Mesh was generated with no problems. Even mesh division fits to surface division.

(gray – model | red - water inlet surface | light blue – air volume)

Obviously both the surface cut and air/water volume division are at the same height.

I don’t know if it has any significant influence on simulation’s run, but to the record:
step zero

final step (for this particular simulation)

Previously, based on your animation, I’ve assumed your step was 0.1 [s]. Now, I tested it and see that it was around 0.005 [s]. - It’s just a small clarification.

Is it a surface model? In that case, now I understand why @quequen was so keen on z-direction degree of freedom. Why did you decide to run it like this? Any particular reason?

Make your life easier and close it :wink:

Looking at free surface and velocity field it’s difficult to believe that pressure and phase ratio converged so well.

I agree with @BenLewis - forces at your hull look random.

In terms of formulas: I’ll try to find some time and look for it. If I succeed then I’ll ask you for some more details.

I’d like to add a few words about results presentation – in general.

  • Remember that you see much more than me, @quequen or anybody else, so try to present your material bearing this in mind. For instance: when I presented results of my ROV simulations my main aim was to give basic information about simulation and show correlation rate between experimental and CFD data. I added colourful pictures just to make the topic more vivid, more attractive and eye catching.

Now, when you add your pictures - in my opinion - you can get rid of all that unnecessary elements from it: interface, frames, blank spaces etc. It will make your pictures clearer.

  • Please, for the same case, try to keep to constant ranges if possible (velocity mostly, because it’s something you can control :slight_smile: ).

  • I really like that reversed colour pattern when you present waves coloured with velocity, but…

  • …I’d like to ask you for one more thing here. When you show us waves, plain (not discrete) palette of colours is very good approach. We see smooth velocity changes – super. But when you show cut planes with velocity or pressure fields than it’s not a good idea - at least not always.

I asked you for cuts as I wanted to check the domain vertical size. From what you presented it looks the domain is both too low and too shallow. In terms of the surface model I’ve already mentioned above and I’ll wait for your reply. Here, however, I’d like to show what the problem is - in my opinion.

Below is your picture in two versions (I cut unnecessary blank part at the top and kept the one at the bottom to keep the scale bar):

As we can see in the first picture there’s a lot going on in the upper part. I omit boat interior, but there is something at the inlet too (green band in the right top corner). Also just above the water table air velocity is worryingly high – I assume the velocity fields are bonded and homogenous (both have the same value).

I wear glasses but still can see some barely visible colour patches below the hull. So I took photoshop (free photoshop online) and played a bit. After a minute or two I got this. It seems there is a significant interference of domain’s bottom.

Naturally if you’re familiar with your problem, ran a lot of simulations than you have a feeling and you know where you can turn the blind eye. But here, I think the domain should be higher and deeper.

Maybe some example from my compressible test runs:
wide colour range palette

discreet palette

discreet palette with slightly different range plus velocity plot along the line

As you can see the domain seems to be high enough. But when you go deeper you discover that it should be a bit higher and maybe even longer.

Of course here delta is about 2.5% and probably I can ignore it, but still… That’s why they often have such ridiculously big domains.

Let me know what your thoughts are.

Seemingly overly large drag values, unsure why

Hi @sjoshi, as @BenLewis stayed, there’s a problem with forces. Total X force (Drag) should become steady after a few seconds. Fixed Z position of the hull shouldn’t be a problem for your velocity and Rn. If something as a Karman Vortex is raising behind the hull, it is not visible in your graphics.
By the way, @Maciek, I personally prefer complete screen captures because in that way part of the interface and settings are visible. I have a lot to learn before using the interface properly :grimacing:
At this stage it is premature to compare with existing and real data, but reaching that point there are many well known studies out there. Perhaps one of the most famous is the Delft Series (DSYHS), Delft University recently published all the data, including hull shapes used on tank testing for over 30 years of studies.

This document may be of interest: An extensive cfd analysis (using ANSYS CFX) of one of the Delft hulls.

And here a related video:


@BenLewis, @Maciek, @quequen

The force plots indeed look quite suspicious - thank you for bringing it to notice.

I will dive in and look where the issue could be and update here.

@Maciek The visualization tactics of scaling the the important range of data values indeed do help convey a clearer message - I shall keep that in mind.


Finally I had time to catch up on this thread! Impressive work @sjoshi! Looking forward to the next iteration of the simulation results - it looks like you’re getting there. My 2 cents on the simulation:

  • Agreed with @Maciek, that the computational domain needs to be deeper to avoid interaction of the flow field with it (I like the expression “ridiculously big domains” :smile: ). However I doubt that this is the main reason behind the incorrect results.
  • @BenLewis: I think @sjoshi is using a local time-stepping method so numerically it’s possible that transient patterns appear towards the end, looking never really like a “steady state”. However I agree that the question is if what we see is physically correct - the drag and lift plots do look questionable. @gholami mentioned that a good way of assessing the quality of such simulation results is running the same simulation with different time-step length to make sure the results are independent of the time discretization. Probably too early right now but once the results look more trust-worthy
  • What about the mesh around the hull itself? On the image it looks quite coarse. Do the result fields close to the hull look mesh-independent? Could be worth looking into this and adding some refinement layers there.
  • @quequen: Thanks for linking to the Delft Series. Great data! This is definitely something we will look closer at!

As mentioned in the beginning of this thread I have little background in boat hull design. Therefore I am also very interested in learning more about the general approach to these design projects in terms of simulation. @quequen: You asked if the boat can move freely in this simulation. This method is in the product backlog and will be integrated moving forward. But how important is this kind of analysis within the design phase? Comparing it to other design processes and applying the old “Crouch, Walk, Run” principle, I would assume that this is rather something I do at the very end of a project as it’s quite computationally intensive and rely on faster steady-state, fixed-boat analysis for the main part. Would you agree or are the assumptions behind this analysis type too vast?


@dheiny, yes I agree: step by step. Regarding oscilating forces, the document I attached previously throw light in many issues about this kind of simulations. Page 20 and figures 16-17 show how forces oscilate for a while before converging and, as expected, this issue reduces when Fn increases (time-step is 0.02s). At page 28, fig. 23 shows that a fixed geometry throw good outcomes up to Fn=0.4 but higher Fn increases dynamic forces too much, therefore agreement with experiments is lost.


Hello fellow engineers,

The problem with oscillating forces might have something to do with the geometry being bad. Here are a few snapshots showing the old geometry with selection of external and internal faces:

As one can see, there exist surface intersections between external and internal surfaces. I chose a simpler geometry that I closed from the top. Now, the geometry is free from surface intersections:

With this geometry, I re-ran the simulation. Now the forces converge to a constant value. Water flows in the -z direction.

Here are the forces in the important directions, i.e., x, and z directions:

Please note that the actual values of these forces might not be accurate, since on the platform only 1 reference density is used for computing forces on the selected surfaces.

The Kelvin Wake remains the same:


Very neat @sjoshi! @quequen and others: I think it’s worth putting together a webinar/tutorial for such kind of simulations to enable new users faster. I think especially the phase fraction concept / initialization of water/air makes this approach a bit tricky in the beginning. What is your preferred way of learning such new methods/softwares? Would be great to get some opinions on this - check out this post: How to best learn simulation?


@sjoshi, it looks great! Some details may still remain but I think you have a strog start point for this kind of simulations. @dheiny I agree, this simulation deserves some webinar/tutorials (perhaps 2 or 3, 15 minutes each?), including voice comments on how to perform the settings, particularly the phases issue. My choice is webinars or tutorials, and a good printed manual (that’s why I asked for a .pdf manual, instead of online manuals). Please remember that my geomety is still there if you want to play with it. I would now try some leeway angle (angle of attack), may be 3 or 4 degrees, bow to port, to catch appendages behavior and a more realistic X force.



regarding how to learn simulation best, we’re in the middle of collecting more feedback and a little survey to steer the type of learning material we want to provide in the near future. I added your opinion there as well!

I wanted now to follow @sjoshi’s work on the boat flow and set up one myself. Did you already upload your model to a SimScale project? If not could, you do it and share the project with me? We could see how far we come before asking @sjoshi for help ;).




@dheiny, I shared a geometry to , can you pick it up from there?
If you send me your e-mail by private message I’ll share with you some other geometries too.
On my boat there is no leeway, wich is bad. A sailboat beating against the wind will heel (like mine), but will also sail at a small angle. There must be a small angle of attack for the appendages (keel and rudder) to produce some lift (“x” force). So the boat should be rotated around a vertical axis, on the xy plane, about 3 or 4 degrees counter-clockwise seeing from the top. Note that in my geometry “x” goes forward, “z” goes upwards and “y” goes sidewards.


@quequen, thanks for sharing the projects directly with me! Just imported the first of them and had a look at the CAD model:

One question regarding the CAD model: It’s in STEP format but the face topology rather reminds me of a faceted file format (e.g. STL or OBJ). Each triangle of the tessellated surface is considered a single face. I would expect that the STEP file defines the big faces (e.g. the deck or the hull) as one single NURBS surface. Would you mind sharing in what CAD system you modeled these? Because to me the STEP export behaves unexpectedly. It might be even better in that case to export it as STL if your CAD system does support such an export. If not, I am confident that we can also work with these files.

Looking forward to seeing some waves around that hull ;)!

'A-Class Mk6' simulation project by lmuehrke

And the Kayak looks awesome! Excited to simulate it!


@quequen, is there a chance that you can get a STEP file out of your CAD system that does not tessellate the surfaces but exports them as NURBS? If not, I’ll use a tool on my end to combine them again. But we might loose surface quality…


No way for me actually. I’m sending to you some .igs and .iges files by private message (Simscale Forum do not accept this kind of files so I can’t post them here).

No connectivity Mesh!

Mhm, interesting that it exports STEP and IGES files like that. What CAD software are you using? I received the IGES files but they show the same effect. But we’re having a seat of a direct modeler here with which it should be possible to “stitch” those faceted faces together. In principle it would also work directly with the models you uploaded, but the mesher would need to deal with a lot of separate faces which might get tricky. Anyways, I’ll give those models now a spin early next week.

On a related note: I just saw my colleague @gholami release-testing the first “moving boat” capabilities. They will be included in one of the next releases!


@quequen, the last models you provided were not that fine granular tessellated and worked much better. It still puzzles me why the exporter of your CAD system works that way. SimScale is used together with a wide variety of CAD systems but that behavior was new to me. At some point I would be interested in digging deeper into this to provide a good interoperability with it.

Anyways - the first laminar sim is now running, heeled about 10 degrees and rotated 4 degrees around the vertical axis. However in terms of water level I was not sure how to adjust it properly. What workflow/approach would you recommend here?

Thanks to @sjoshi, the setup was quite straightforward - I copied it and changed a few numerical settings:

Will post the first results once, they are there!


So - design by @quequen, simulation by @dheiny :wink:

Not quite there yet:

  • the refined mesh region around the hull influences the interface quite a bit
  • solution not yet converged (another simulation already kicked off)

I’ll do more post-processing tomorrow (some quantitative results regarding drag and lift) - anything else that catches your eye in these initial results?

Animation of the air-water interface color-coded by velocity approaching steady-state:

Static image: