[Hannes_Kiel]

Hi Vince,

from the description in the paper, there is actually quite a bit of in-house code involved.
- MHRIC: Basically, this is a variant of the HRIC scheme by Muzaferija (sp.?) & Peric, designed to have compressive properties within the convective transport of the VoF-scalar. The formulae can be found in another paper from the workshop: "Numerical simulation of wave induced
motion of a floating body". From my experience it is supposed to omit the Courant-no. dependency of the HRIC scheme, albeit at the cost of robustness. I'm actually pretty happy with the standard HRIC. For the implementation of those more complex div-schemes take a look at the naval-foam package in the extend repository.
- DFBI: The way it looks to me it is not Dynamic Fluid Body Interaction the way it is meant in Star-CCM (implicit or strong coupling of flow and body motion, see PhD-Thesis by Yan Xing-Kaeding, TUHH) but a quasi-static update of the position every 200 iterations. In the standart implementation of LTSInterFoam, to the best of my knowledge, body motion is not intended.

Hope this helps.
Hannes

[vonboett]

I would like to add something with respect to multiple refinement steps by calling snappyHexMesh (with castellatedMesh true) and refineMesh several times: To my experience, one runs into trouble if the cells you want to refine do not lie inside or outside of the cellSets or regions that were refined in prior steps. If the actual cellSet (or refinementRegions etc.) includes those cells that form the transition between a coarser and a finer grid resolution, one ends up with mesh errors. Mayby this can help someone to understand success and failure of repeting refineMesh or snappyHexMesh steps.

[Hannes_Kiel]

I totally agree. As a remedy, the cells to be refined can not only be defined by region, but by cell level (or volume) as well.

Originally Posted by vonboett

I would like to add something with respect to multiple refinement steps by calling snappyHexMesh (with castellatedMesh true) and refineMesh several times: To my experience, one runs into trouble if the cells you want to refine do not lie inside or outside of the cellSets or regions that were refined in prior steps. If the actual cellSet (or refinementRegions etc.) includes those cells that form the transition between a coarser and a finer grid resolution, one ends up with mesh errors. Mayby this can help someone to understand success and failure of repeting refineMesh or snappyHexMesh steps.

[Sachin m]

Has anyone tried simulation of a vessel with a trim.??
I would like to simulate a ship with a trim of 7 degrees. Is there anyone who can help me out with this?

[Hannes_Kiel]

Hi Sachin,
I'd suggest you transform the geometry prior to meshing, e.g. by using surfaceTransformPoints.

Best Regards,
Hannes

[Sachin m]

Thanks for the reply hannes

[Rasmusiwersen]

Originally Posted by colinB

Hi Andrea,

to avoid the mentioned error message and to
prevent you from copying folders and so on you could also
use the -overwrite flag for some of the commands.
That works for me.

So the workflow looks like:

1. blockMesh
2. snappyHexMesh -overwrite
3. topoSet
4. refineMesh -dict -overwrite
( till now checkMesh is very good !! )
5. snappyHexMesh -overwrite

This is the part that did it for me, although i didn't repeat step 5. I do get errors with exceeded MaxSkewness and non-orthogonality cells, although so far I've been able to get rid of them by increasing

nSolveIter
nFeatureSnapIter
nRelaxIter

in the snappyHesMeshDict.

Hope this helps (Y)