CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Running, Solving & CFD (
-   -   InterFoam very small timestep (

unoder November 23, 2005 07:06

Hi, Could anyone please hav

Could anyone please have a look at this case and tell me if it's normal for the timestep to be so small - and perhaps it's getting smaller yet (1E-7 sec)? I think there's something wrong here, perhaps boundary/initial conditions?

nCorrectors is 3 - the geometry consists of hex elements. checkMesh doesn't complain about any "severe errors" - a little output (although I don't know what exactly it means):

Checking geometry...
Boundary openness in x-direction = -1.75251e-18
Boundary openness in y-direction = 5.40229e-17
Boundary openness in z-direction = 4.90284e-17
Boundary closed (OK).
Max cell openness = 8.47039e-22 Max aspect ratio = 1.00033. All cells OK.

Minumum face area = 2.12057e-06. Maximum face area = 2.35618e-06. Face area magnitudes OK.

Min volume = 3.19848e-09. Max volume = 3.51656e-09. Total volume = 0.000134475. Cell volumes OK.

Mesh non-orthogonality Max: 0.106083 average: 0.00296587
Non-orthogonality check OK.

Face pyramids OK.

Max skewness = 0.181423 percent. Face skewness OK.

Minumum edge length = 0.00141371. Maximum edge length = 0.00157079.

All angles in faces are convex or less than 10 degrees concave. hexbody_rund_meshed.tgz

I also had this problem with the timestep when I tried to do a calculation with tet-elements, so I'm pretty disappointed if this won't work when I've switched to hex-elements, if you understand :-)

unoder November 23, 2005 10:04

Ok, the solution seems to be h
Ok, the solution seems to be here:

"5. That flow speed is awfully slow. Given that gravity is switched on in the dambreak case, your inlet is likely to run "dry" (fluid moves away from the inlet faster than it enters). This will cause the code to diverge, because of a surface tension-gamma gradient related problem (check old posts for details). If the inlet is from below, none of this matters of course. "

However, I made a setFieldsDict which doesn't work - I don't understand why... This is supposed to be simple - perhaps a bug? No errors, by setFields, yet nothing happens.

Download the modified case here, 1) run blockMesh, 2) run setFields, 3) Bug report?: hexbody_rund_setFields.tgz

shu November 23, 2005 11:28

Hi Martin, I have the same pr
Hi Martin,
I have the same problem with the too small time step as you, i.e. the velocity is too high (1e+5). So I am also looking forward to know the solutions.

To set the gamma-field I have got a program for you. It is derived from the setGammaDamBreak of the Version 1.1.


shu November 23, 2005 11:29

Hi, I have the same problem w
I have the same problem with the too small time step as you, i.e. the velocity is too high (1e+5). So I am also looking forward to know the solutions.

To set the gamma-field I have got a program that is derived from the setGammaDamBreak of the Version 1.1. setGammaField.tgz


unoder November 23, 2005 15:08

Hi Bitan, Ok thanks - I'll
Hi Bitan,

Ok thanks - I'll try your program if nobody can (or will) explain why setFields doesn't work...

hjasak November 23, 2005 15:15

I don't want to be rude... but
I don't want to be rude... but setFields does actually work: try the interFoam tutorial and you will see it in action.


unoder November 24, 2005 09:15

I have seen setFields work man
I have seen setFields work many times, but what I'm asking for is the explanation for why it doesn't work here.

mattijs November 24, 2005 14:49

because your 'boxToCell' setti
because your 'boxToCell' setting in setFieldsDict is

box (-1 -1 1) (1 1 1);

unoder November 25, 2005 14:11

Hi Mattijs, Ofcourse it sho
Hi Mattijs,

Ofcourse it should have been

box (-1 -1 -1) (1 1 1);

Have you tried that? Doesn't work and now I get this error with paraFoam:

> paraFoam . hexbody_rund
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.2 |
| \ / A nd | Web: |
| \/ M anipulation | |

/home/martin/OpenFOAM/OpenFOAM-1.2/bin/paraFoam: line 57: 16578 Segmentation fault paraview paraFoam.pvs

hjasak November 26, 2005 04:51

I have just tried your case an
I have just tried your case and it worked first time. I have even fixed the bounding box that was commented out (again xMin and xMax the wrong way around) and initialised it).

Here's a picture:

I think you should have a look at your installation. I don't remember fixing anything but if you'd like to have a go at my development version, pls give me a shout and we'll find a way.



unoder November 26, 2005 17:56

Hi Hrvoje, You write someth
Hi Hrvoje,

You write something about xMin and xMax the wrong way around? I tried to swap all values like this: box (1 1 1) (-1 -1 -1);

I also tried swapping x-values in the original setFieldsDict to become: box (0.135 0.1 0) (0.15 0.15 0.015);

I don't understand this: I get *no error messages* and still nothing happens. What exactly did you do? I don't see what exactly I'm doing wrong here. I tried setFields on 2 different linux machines.

Also, I suppose I don't get any problems with the timestep using this mesh now, would I? (last step is "interFom . hexbody_rund". Perhaps it would be easiest if you just upload the case here and I can download it and see what you changed.

Last thing: If the development version is stable and better, I might be interested. As you see, my paraFoam/paraview is now screwed up so I guess I'll have to reinstall. Do you (or anyone else) know when we could expect OF 1.3 to be available?

hjasak November 26, 2005 18:16

OK, here comes: box (-1 -1
OK, here comes:

box (-1 -1 -1) (1 1 1);

runs straight out of box: no error messages, no warnings etc and all is well. However, the whole mesh is inside your box so it all gets initialized to 1

box (-0.15 0.1 0) (-0.135 0.15 0.015);

also works. This used to say:

box (-0.135 0.1 0) (-0.15 0.15 0.015);

which runs but des not do anything. Remeber, the specification for mins and max will need to have
(min_x min_y min_z) (max_x max_y max_z).



unoder November 27, 2005 08:47

Thanks a lot for your time,
Thanks a lot for your time,

I think the utility ought to print out a warning if (min_x min_y min_z) (max_x max_y max_z) is not entered correctly. No error messages sounds like nothing is wrong and if you don't know the program it sounds like a bug. Ok however, Foam looks like an excellent software package, at least "if you know how to do it" :-)

Okay, so the problem wasn't so big. I did a test run with a coarse mesh. Now, I'm wondering why I don't see symmetry here - there must a "scientific" explanation.

Since the boundary condition is symmetric then one might suspect the solution itself would also be that. What's the explanation? Instability? I agree this mesh is very coarse - I just did a very quick computation here.

Also, I really had to make a very long inlet in order not to "run dry" (bigger than shown on the picture). I didn't expect it would be so big, in order to fill this geometry completely. Isn't it possible just to make a boundary condition with "endless" gamma?

I also guess that if I made the outlet area (patch) smaller, for instance 1 by 1 cell then the back pressure would be higher/bigger and filling would be quicker. Right?

All times are GMT -4. The time now is 10:20.