[lt.quibbler]

Hello, dear foamers!

I've faced a very interesting problem using interFoam 2.1.x for the prediction of the resistance for Kriso Container Ship (KCS).

On relatively high Froude numbers ( 0.22 - 0.28 ) solver gives very good results compared to the experiment, but when I diminish the Froude number the results get worse.

For example, the coefficient for the total resistance on Froude number 0.1 is twice higher
than it should be. And it is so due to high values of pressure force, which is in this case 70-100 percent of the viscous force and oscillating.

When I tried to use pimpleFoam ( for 1-phase problem with symmetry plane) on the same Froude number for the same ship I got correct result. The error for resistance is about 10 percent.

Has anybody faced similar problems?
I just want to know if it is my fault or it is a well-known problem.

Thanks in advance!

[vonboett]

...well after others reproduced the same bug, I sent a bug report concerning interFoam, in this case only affecting the outlet boundary condition but maybe your case is affected too. See the bug report here: http://www.openfoam.org/mantisbt/view.php?id=554

[lt.quibbler]

Albrecht, I have taken a look on the bug. What BC's for p_rgh do you use?

[vonboett]

Hi lt.quibbler,

I have tried with several settings, in the case shown I use for the outlet:

type outletInlet;
outletValue uniform 0;

and for the atmosphere (top of domain) that reflects the phase aswell I use:

type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rho;
psi none;
gamma 1;
value uniform 0;

I would be happy if you could tell me if you can reproduce the bug.

Thanks,

Albrecht

[lt.quibbler]

Hi, Albrecht!

Unfortunately, I cant reproduce this bug even using outletInlet. Perhaps you could send me your case? I would take a look if the bug can be reproduced for the same case on my version of FOAM.

[vonboett]

Hi Ivan,

Thank you for testin!. The case worked on OF 1.7 but produces no outlet if used in OF 2.0 or 2.1.x. Tha attached case (only the basic files) is the working one with x- coordinates smaller zero. To reproduce the bug shift the vertices in blockMesh into positive the positive quadrant.

[vonboett]

Hello Ivan,

meanwhile I reproduced the bug on a Mac OS x 10.6.5 intel, using OpenFOAM 1.7.x.
I attatched the corresponding case folder with positive x coordinates. Again, the bug vanishes when the vertices are moved by -7 m in x direction to the negative quadrant. To create the mesh and run the case, create the polyMesh folder and move the blockMeshDict file in it, had to remove the mesh files due to attatchment size.

Could you post me your case files that dont show the bug, eg. blockMeshDict, alpha1, p_rgh and U as well as svSolution and svSceme ?

Thanks,

Albrecht

[lt.quibbler]

Hi Albrecht!!

I think I know what is your problem. You mirrored the mesh, but you forgot to change g from ( 4.905 0 -8.495 ) to ( -4.905 0 -8.495 ) ( the same reflection as for the mesh ). In the case if u dont change the gravity force direction your gravity force makes the fluid go to opposite directon from the outlet.

At least it worked for me.

Please, check if it is the case for u.
Regards

[vonboett]

... no I didn't mirror the mesh, I yust translated it. However, using for p_rgh zeroGradient at the outlet works, at least in OF 1.7.x, I will check this on OF 2.1.x tomorrow, thought I have already tried this.
But the reflection on the atmosphere gives me still a headache.

[lt.quibbler]

Perhaps, I did the wrong manipulations in blockMeshDict =) Could you, please, send me the version of the case in which I wont need to change anything? Just to run and see the bug

[vonboett]

Hi Ivan thanks for your time! I cant attatch the grid its too big, yust create the polyMesh folder and move the blockMeshDict from Constants to Constant/polyMesh and then call blockMesh before calling interFoam.
What version of OpenFOAM do you use? This case flumeOutletTestX+1,7 is modified to fit to for OF 1.7.x.

Best wishes,

Albrecht

[lt.quibbler]

I finally reproduced the bug on interFoam 2.1.x

Unfortunately, I cant try another BC's right now.

I think that something is wrong with the direction of the normal to the boundary...

Best regards,
Ivan

[vonboett]

Hi Ivan,

thanks for confirming. Henry does not see this as a bug, when using zeroGradient at the outlet for p_rgh the strange behavior vanishes. He is right, it works aswell on OF 2.1.x when using zeroGradient at the outlet for p_rgh. My problem is I have to explain this to my PhD supervisor, and the only guessed explanation I can think of is that it has to do with reintroducing the plus/minus sign after performing calculations with abs(p_rgh) at the cell faces somwhere deep inside the code, but guessing is not explaining.

Anyway I am happy that I can continue with my simulations, but if someone ever finds an explanation I'd be happy to hear from it.

Best wishes,
Albrecht