Hi guys,

I found in the past that the wave pattern becomes better when you strech the cells in the sailing-direction. This seems to smoothen the waves a bit (this trick is also used for panel-codes).

Good work on the other topics. Meshing within sHM seems a problem with the boundary layer; I'm working right now with Hypermesh for meshing... is to be continued.

By the way; if you want to try shipFoam (isn't a proven solver) use the original version for OF1.6.

Cheers,

Ralph

Hey Ralph,
Out of curiosity, did you ever manage to fix the pressure issue for 1.7? Also have you ever tried using relative=true for the BL mesh? I personally have not tried it, but others here have said they managed to get reasonably good bl meshes on hulls as long as the refinement level was the same all over the hull.

Ben,
I think you will find interDyMFoam to be pretty unstable. A linear ramp to the application of force for the motions would help but that requires delving into the code to modify it. Heavy dampening is good too and some moment of inertia as well. If you managed to get interDyMFoam working I would be interested to know what you did.

Regards,
Dave

Hi Dave,

I tried a lot with meshing and the different solvers but I didn't had a look into the point that you mention. At this point I've had it with sHM; I want more control over the boundary layer and a prettier mesh. I did take a look into the pressure stuff for shipFoam for OF1.7 but I simply don't know enough about programming and its structure to mes(s)(h) (haha, that's funny) with it. I tried to work it out for a couple of months but it simply takes too much time. (and I don't want to spend my time any more on this :P).

About your other remark; I think a lot of people would be interested in the improved interDyM code (which would actually be something like shipFoam?); I'm curious for the results!

Ralph

Ralph,
Understandable about the programming for shipFoam being very time consuming (and giving up on sHM). Snappy has a lot of good features about it, but ultimately it's boundary layer application does seem to be its biggest pitfall. I am considering salmone and engrid as alternatives to snappy for that reason. The linear ramp should be fairly straight forward to apply and seems like an obvious step to add (though I have not had time to add it myself). I don't quite think it is comparable to shipFoam in that all one is doing is spreading out the time over which forces are applied to help cope with initial destabilizing conditions. Commercial codes tend to have it as a standard feature and I use it all of the time in star ccm+ for calm water resistance.

I've always wondered about the pressure issue since it appears to be a mesh motion induced problem (given that it doesn't happen in interFoam), does it have to do with the grid flux terms? In general they are the mesh motion's effect on the flow field. Ignoring them means effectively ignoring the velocity and acceleration effects of moving the surrounding mesh. Doing so however tends to be much more stable (though technically not conservative). It also means you have lost temporal accuracy, but if you are only looking for a steady state it is fine.

What is strange to me is that my first set of coarse mesh runs ran fine in interDyMFoam (though not stable in trim since it wasn't ramped or damped enough) but subsequent runs always blew up. There is a lot of stuff I need to go back and look at after September when I have time.

Dave

Hi All,

I've been playing a bit with the interDyMFoam solver and, as Dave said, it runs sort of ok for very coarse meshes but gets dodgy when going above 200k cells (in my case at least)

Courant number is very critical and initial time steps have to be set to a very low value because the boat trims very fast, messing up the stern wave massively. For a 9m boat at 8kts, I need to set it to 1e-4s for a 100k cells mesh and 1e-5 for 200k cells in order to get something out of it.

I also found that running in parallel is less stable and I need to decrease the time step even more. Any idea why that is? Its quite annoying because it makes it even less productive to have fine meshes...

After the first half second or so, timestep can be increased to a more descent value and then it all goes sort of ok.

I left a coarse run overnight and after about 10s, when the boat's wake hits the outlet, the water level starts to raise, some oceanic swell appears and then it all goes into sea keeping mode (it goes wrong!), eventually crashing at about 30s. So I guess that my outlet BCs are wrong. I've been using zeroGradient, as per the wigley hull tutorial.

What are the recommended outlet BCs? I've seen that totalPressure should work better but don't really have a clue about it... any ideas? Maybe my domain is too small at 3.5 boat length downwind and 2.5 sideways ?

Bellow are screen dumps of the free surface at t=8.4 ; 16.5 and 29.5s (crashed at 29.9s)

regards,

Ben

I am also getting a very sketchy forces output. Any idea where that could come from?

Regards,

Ben

Edit: I have plotted velocity fields at 0.1s and the velocity gets really high from about 1/5th of boat length fwd and aft of the transom (peak at 23m/s for a 4m/s mean flow).
So it is this zone that is limiting the timestep. This high flow velocity zone then disappears later in the run, hence time step can be increased.

Is this a mesh issue again? It seems fine with max skew in that area at 2.7...

Hello Ben,

I'm afraid that your problem is a general problem within OF and its multiphase solvers. I had these problems too and so far I know there are no proper outlet BCs. Colin Barth (also forum-member) is investigating these problems. He is/was trying to come up with a numerical beach but I don't know its actual status.

For all multiphase problems the waves from the outlet start travelling upstream and mess up the results. Although it looks like it doesn't appear in the wigley-tutorial it will occur there too (after more time steps).

So the temporary conclusion is that a larger domain is needed; this will give the calculation more time to converge near the ship.

Another trick that I found useful is to start dynamic mesh calculations with a fixed ship position for the first few time steps. This will stabilize the flow and pressure fluctuations. When these are stable/converging (you can see that at the forces-output) you can switch the dynamic bahavior on.

Cheers,

Ralph

Hi Ralph,

Thanks for the response. I will increase my domain size when I'll be looking at getting some numbers out of that.

I had a look at the navyFoam solver docs and it seems that they have developed their own boundary conditions for this very same reason (called calmWater)...

When you say starting with a fixed ship position, does it means that I should start with interFoam then switch to interDyMFoam later or is there a way to fix the motions directly in interDyMFoam?

Regards,

Ben

Hello Ben,

You could do that, but I'd suggest that you change the dynamicMeshDict (under constant). I thought that it must be possible to change the input there (not sure).

Another option could be to fix the hull in the points-file in the "0" folder. Options for this file are also described somewhere on this forum. (sorry that i don't have the exact solution for you, I'm at my work right now...)

Ralph

Ralph,
The reflecting waves are typically eliminated in commercial solvers with a vertical dampening term applied near the outlet. The documentation in starccm+ goes into detail about it but I am not sure whether I can post stuff out of there. As a mesh based method, one can also use a coarse mesh near the outlet to provide mesh based numerical dampening. Basically provide fine refinement right at the still water level and then just above and below go to coarser meshes quickly such that the numerical dampening can take place. In either case a bigger domain allows the waves to ship wave train to be damped out without affecting the solution in the nearfield. The bouncing wave issue becomes less of an issue at higher speeds.

Ben,
I am suprised that 100k and 200k is already causing trouble since I had runs with 400k run with no problem (of course I didn't run them for 30 seconds so they may be unstable by that point as well). I also agree with Ralph that starting with a fixed run for even a few tenths of a second helps with stability alot as well (consider that typically there is usually a spike in the forces at the first couple of time steps which is possiblly part of the cause of the rapid trim you are seeing). It is possible to fix the hull in interDyMFoam but it still requires a restart to switch to moving so it its really your choice on using it or interFoam. You can discover the right replacement in the dynamicMeshDict by putting a incorrect replacement term in and trying to run it since it will spit out a list of the acceptable replacements (one of which fixes the object though I forget the exact form of it off hand). Looking at your screenshots, another suggestion is to move your inlet a little further away (a boat length away) to make your solution less sensitive to the inlet conditions.

Dave

Hi Dave, Ralph,

The command to fix the mesh is simply "staticFvMesh" but yes, you need to stop and restart the solver to have it working, plus copy the pointDisplacement files over the latestTime folder.

Were you using a structured mesh and did you have some surface layers when you were running at 400k cells ? Note that I am running a half hull so I guess a full one at 400k would work since Co will probably behave the same as now.

I think in FineMarine, the trim/sink is adjusted every n timesteps and the new position determined in a semi-static way (calculates equilibrium from forces at latestTime and re-trim the boat to match) so this is done without any acceleration or dampening and makes it much more robust and quick to converge to steady state.

I am clueless about programming but would it be complicated to "stitch" together the motion solver and LTSInterFoam in order to achieve the same effect as in FM or StarCCM+?

Regards,

Ben

Edit: I think I found the reason why the timesteps were becoming so small: I started off with a random damping factor for pitch and, as I could see that pitch motion was going into high values, I've been increasing it several times, thinking that would damp the motions. It ended up making the opposite effect to what I was thinking it would do, hence the high Co for a small time step...
I have now set damping to 10 and time steps are around 2e-3s.
Looking at the file linearAxialAngularSpring.C, I don't really understand why a damping factor set to a low value will damp more than a higher value...

try "-banana" in the position of a command. You can find at this forum more info when you look for this term :)

Ben; when you want to stitch LTSInterFoam and a motionsolver together I'd suggest that you search this forum for shipFoam and also take a visit to the shiphydromechanicsgroup over here (check the link below my posts). Maybe you get some idea how to tackle this problem. I think there are some people willing to assist you on this problem (myself and I think Dave and Colin Barth as well).

Let me know!

Ralph

Hi Ben,

If you want to follow the FineMarine scheme, you can do it even without programming, just with scripts with LTSinterfoam, translatepoints, mappingfields etc...

If you decide to modify/use openfoam it would be better modify interdyfoam or shipfoam for 2dof with solid body motion, and remember allways update your alpha1 inlet or you will get waves.

Ben,
I am surprised about the dampening coefficient because I had posed the question about whether it has dimensions or not and had come to the conclusion that it did. That is to say that increasing it increased the dampening force as opposed to a value of 1 representing critically damped, greater than 1 over damped etc. Therefore it is strange that decreasing the value of it reduces motion.

The way you describe FineMarine sounds like it does ignore the grid flux terms for the body motion. If that is the case it means you might not be able to do sea keeping accurately, but I think at this point I would settle for calm water resistance. I have thought about the idea of incorporating LTS into a dynamic case though it is not clear to me how the motion would be handled. In the case of starccm+ they use a global time step followed by a set of inner iterations where the time is marched locally based on local Courant number. The inner iterations converge the solution at a given global time. The motion update occurs with the initial global time step. It is very robust but radically different from interDyMFoam in its approach (unsteady SIMPLE among other things).

Another thing out of starccm+ that I think is quite good is one of the motion options is to translate and rotate the entire domain while leaving the solution in its place without deforming the mesh. It is far quicker than mesh deformation and more robust, but does have the disadvantage of needing a fairly thick layer of cells near the free surface to account for trim and heave changes.

I suspect that the combination of these two things out ccm+ is very similar to what you would have to do to provide motion to LTSinterFoam. I think that Pablo may be right about it being possible with a very extensive script file and I think you would have to wrestle with groovyBC to allow for the updates to the BC at each time step.

As an aside, the runs I did successfully where with 400k on a half domain (though for maybe 8 seconds). Mesh was made in sHM but did not have a boundary layer prism mesh.
Dave

results with LTSInterFoam
 

Hi all

Like I said in my last message, I'm testing LTSInterFoam on a french fishing vessel.
Like I haven't results from towing tank test, we had compered results from OF with results come from a commercial CFD code and linear regression analys. I post the graph of results.
I used for meshing, SnappyHexMesh with 2 000 000 cells.
But I have some perturbations on free surface. Now I test the method where the refinement is make under BlockMesh and only the snap with SnappyHexMesh but for the moment LTSInterFoam diverge. What's the problem? A bad repartition of cells?

Regard

Vincent

Vincent,

You are seeing the same as Ben did earlier. At the moment try to stretch the cells in x-direction (simply by defining less cells in the blockMeshDict in x-direction). This will smoothen the free surface; as a bonus it will make your calculation faster since less cells are involved :D

Cheers,

Ralph

Bonjour Vincent,

I have posted the blockMesh file that has some kind of refinement around the hull a few pages before. Take a look and modify it to suit your case, it should help you to get rid of those waves. Then, if you are keen, you can make it better and add some extra refinement around the bow / transom / wherever. It is quite tedious to do but not hard.

You need to make sure the shape of the cells at hull intersection is close to a cube in order to reduce the skewness.

Ben

Hi Ralph,

It seems that shipFoam would be the answer but, looking at the forums, it only seems to work with OF 1.6-dev, am I correct? Did you get some sensible drag / lift values with this version? Were the trim / sink matching experiment? are there any plans to make a shipFoam version for OF 2.0 ?


Dave,

I am struggling quite a lot to get anything sensible out of a mesh finer than 150k cells. Above that, I am getting the stern wave extending all the way across the whole domain and eventually a trough starting a few m fwd of the bow extending aft of the stern and going across the whole domain. I have no idea why / what I am doing wrong...
I guess it is related to the pressure issue that shipFoam tries to sort out but I'm not sure.

I have tried to play with water density and viscosity but still getting that issue.

I am not looking at doing any sea keeping since I am only studying small yachts. That is why I am only interested in the steady state attitude of the boat. I know some commercial panel codes do the trim / sink very well but they are commercial so not available to me!

Also, when looking at the pointDisplacement file after reconstructing the solution, I can see that there are acceleration damping coeff and maxAcceleration value set in. max acceleration is set to 1e300 and damping set to 0.

I tried to set acceleration to 100g but the run crashed after a few iterations. I also tried to add some damping but it crashed too... Have you played with those values before?

Pablo,

I am way too bad at scripting to do what you are suggesting, although I wish I had enough time to get into doing that...

I don't understand what you mean about updating the alpha1 inlet. I would have thought that the phases at the inlet are not varying with time / mesh update at some other boundaries? If I am wrong, would that mean that at every timestep / mesh motion the inlet should be updated in interDyMFoam? Sorry for being dumb!

Regards,

Ben

Hi Ben,

Update alpha1 at the inlet is when you move all the domain like solid body, it means a simple translation of points of the mesh based in trim/sink without solve any equation.

Pablo

Hello Ben,

ShipFoam is indeed running on OF1.6 but it is not very difficult to run both OF1.6 and OF1.7 and OF2.0 on the same computer. Just add the following lines to the bottom of the bashrc file (open with ):

You can add in the bashrc-files in the different directories the line: . In this way you'll have a confirmation that the correct OF-version is running. When you start working with OF, chose the correct OFversion, i.e. by typing .

With regard to your question; I tried to get it running for OF171 since I thought the results from shipfoam for 1.6 were reasonable for a fixed ship. Ship motion, however, was already a pain in the *** and needs a lot of tweaking (I still didn't managed to get it to work properly :( )