Hi,

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

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

http://www.cfd-online.com/cgi-bin/Op...=1122#POST1122

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]

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.


Greetings

[shu]

Hi,
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

Greetings

Hi Bitan,

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

[hjasak]

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

Hrv

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

[mattijs]

because your 'boxToCell' setting in setFieldsDict is

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

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: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

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

[hjasak]

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.

Regards,

Hrv

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]

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

Enjoy,

Hrv

Thanks a lot for your time,

1)
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" :-)

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

3)
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?

4)
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?