Collaborative simulation project? Multiphase flow around a boat hull

[Maciek]

Hi @sjoshi it’s great someone continues this thread!

As @quequen seems to be a bit deeper and up-to-date with the topic of hull’s design – I had the lectures and some practice years back now – I’d still like to add something from me.

I’ll focus on your last outcomes as I assume these are the best one so far. So I took your animation, cut the very last frame and this is what I’ve got:

(Sorry if I missed it in text.) Roughly measuring the distance behind the hull is about ten times the length of a yacht. The width is more than five time the hull’s width – I like it. But what I don’t like and don’t understand is why there is such a small gap between domain inlet and yacht’s bow? Look at the picture above (and your earlier picture, orange one too). Didn’t you notice that? (Sometimes it happens that we miss obvious things )

I assume the water table is expected to be flat (no waves), but here we can see clearly some wave is forming in front of a bow. – The same phenomenon you can observe in your previous simulation (!) - I would say you should move the object further down the domain and I would keep the other dimensions as they are. It’s nice to read your discussion about wake shape, but don’t forget about what’s happening in front. BTW residuals go smooth and stable with it?

Also: the time step here seems to be 0.1 [s] (animation contains of 81 frames). It’s fine. But with domain size at 30 [m] and velocity 3.73 [m/s] the time of 8 [s] you set hardly covers (or even doesn’t) the time that a particle of water needs to travel from the inlet to the outlet. If you start your simulation with zero velocity it’s not enough.

You have written you had quadrupled the domain size. Personally I think it’s not the right way. Not at this point. First I’d like to get rid of that wave at the inlet, obtain smooth and undisturbed inflow and only then move my attention to the wake.

So please, if you could run this simulation in approximately the same domain, but move the object about two hull lengths back. You have the precise values, but I’d like to ask for domain and object placement like this:

And, if you start with zero velocity, I’d like to see results after at least 16, maybe even 18 seconds minimum.

Big PLUS for you for running this simulation with full hull, without symmetry.

Finally, could you paste in velocity and pressure fields at symmetry plane? @quequen mentioned something about shallow water and draught, so I’d like to see if there is any influence of domain bottom at it.

[sjoshi]

Sorry for the hiatus! There were multiple things in the simulation definition that needed correction. I will summarize them here:

Domain: The aim of this simulation was to capture the Kelvin pattern of a boat. As described in depth by @quequen, this required a certain constraint on the size of the domain (19 degrees spread on each side). Also, as @Maciek rightly pointed out, the boat needed to be places at a distance from the inlet. Finally, the bounding box was altered to keep a distance of approximately 2 boat-lengths to the front and sides, and 4 boat-lengths behind the geometry.

Mesh: There were two main issues with the mesh. The first was about the refinement at the water level not being fine enough to capture the waves. That was corrected by setting a base mesh of discretization of 0.5\text{m} in x, y, and z directions - on top of this, the boat was refined to level 4, and the water surface to level 3. Region of refinement of the water surface was about 0.5\text{m} above and below the water.

The second issue with the mesh was the generation of waves at the inlet in the solution. This was being caused as follows:

• For this simulation, the inlet was split into air inlet and water inlet. The boundary between these faces was located at -0.4\text{m} in the z direction.
• However, during meshing, the interface was moved a little since it naturally could not be aligned exactly at that distance. It was a little higher than -0.4\text{m} (-0.375\text{m}, to be precise).
• When initializing the water phase, I was using a domain-based initialization method, and the height of my cartesian box was exactly at -0.4\text{m}. This was causing the inlet to be a little higher than the initialized domain, and caused the formation of waves at the inlet.

• After realizing this issue, I modified the cartesian box height to -0.375\text{m}, and the problem was solved.

Solver settings: The solver being used was the LTS (Local Time-Stepping) Multi-Phase solver. In essence, the “time step is manipulated for each individual cell in the mesh, making it as high as possible to enable the simulation to reach steady-state quickly”. It took a while to get the combination working, but eventually stable runs were possible. I ran simulations using two time-steps: 0.005\text{s} and 0.0005\text{s}. Runtime was 20\text{s}.

Steady State for 0.005\text{s}:

Steady State for 0.0005\text{s}:

Clearly, 0.005\text{s} timesteps failed to capture the nuances of the Kelvin pattern of the boat’s wake, while the 0.0005\text{s} timesteps were fine enough to take into account the sensitive wake phenomena.

The following animation shows the solution approaching steady-state with time:

The project will be in a share-ready state by Monday. Thank you for all the help, @quequen, @Maciek!

[quequen]

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?

[sjoshi]

@quequen

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:

Drag:

Lift:

Convergence:

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:

[BenLewis]

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.

Assuming:
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

[Maciek]

MODEL POSITIONING
O, now positioning looks much better to me.

Also @quequen let’s don’t push it too much at this stage 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.

INLET CUT
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)

SIMULATION TIME STEP
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.

MODEL
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

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.

RESULTS PRESENTATION
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 ).

• 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.

[quequen]

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
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.

Hydrodynamic Modelling of Hulls Using RANSE Codes

[sjoshi]

@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.

[dheiny]

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” ). 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?

[quequen]

@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.

[sjoshi]

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:

[dheiny]

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?

[quequen]

@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.

[dheiny]

@quequen,

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 ;).

Best,

David

[quequen]

@dheiny, I shared a geometry to support@simscale.com , 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.

[dheiny]

@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 ;)!

[dheiny]

And the Kayak looks awesome! Excited to simulate it!

[dheiny]

@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…

[quequen]

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).

[dheiny]

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!