[paka]

Some strange thing happens while I'm running one of my simulations. I'm running my job in parallel. Some of the grids ran fine, but others at different times produce such a strange error with extremely huge alpha field numbers. How come is it possible? I'm using interFoam solver.

Interesting is, that for larger time-step simulation ran fine.

Below please find output from my file:

Courant Number mean: 0.0097294 max: 9.31111
Interface Courant Number mean: 0.00150258 max: 6.29323
Time = 4.681

MULES: Solving for alpha1
Liquid phase volume fraction = 0.0377748 Min(alpha1) = -19730.1 Max(alpha1) = 17562
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0377758 Min(alpha1) = -59502.8 Max(alpha1) = 58261.1
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0377768 Min(alpha1) = -162905 Max(alpha1) = 183859
MULES: Solving for alpha1

[wyldckat]

Greetings Kristian,

Well, by your description, I can't figure out if:

• the crazy alpha values occur only when you change the number of sub-domains; for example, works fine for 1, 2 and 4 sub-domains, but goes off the chart with 3 and 5 sub-domains.
• or if the crazy alpha values occur with different mesh resolutions, but with the same number of sub-domains.

Either way, you should check your meshes. For example:

checkMesh
for a in processor*; do checkMesh -case $a; done

This way you can check both the base mesh, as well as the meshes for each processor. Honestly, I'm not sure if there are situations where the decomposition of meshes can lead to loss of mesh sanity (not a technical term, AFAIK), but it shouldn't hurt checking it just in case.

The other possibility is that you might have stumbled upon a bug; if so, you better test first with the latest OpenFOAM 1.7.x before reporting it as a bug. I vaguely remember seeing similar issues described here in the forum, so I think that it's either an occasional bug or it has already been fixed.

Best regards and good luck!
Bruno

[nimasam]

hi Bruno Santos
im using a modified version of interFoam for evaporation i have some strange dependencies to grid size and time step and with alpha sub cycle,
for example there is a linear relation between time step and my answer!!! when i reduce time step i have a faster evaporation for given time!!!
it makes me some how confused can i send you my solver to find out what the problem is?
do you have any idea?

[wyldckat]

Hi Nima,

I'm sorry, but I have barely any clue as to what you're talking about My experience with OpenFOAM so far has been mostly oriented to "making it work", rather then getting down to the CFD engineering part

The only thing that comes to mind about the problem you are having is that when you are changing grid sizes or time constraints, you're not taking into account the physical limitations of the model. And I say this because I've been playing around with the icoFoam cavity tutorial and I noticed that the equations stated in the User Guide about this tutorial, really need to be taken into account, namely Re and Co (Reynolds and Courant numbers).
Similar equations should be taken into account with the interFoam related models, especially since (if I'm not mistaken) interFoam simulates real time and not stationary simulations. So, it's more sensitive to time constraints. (I'm basing myself solely on the damBreak tutorial case!)

Best regards and good luck!
Bruno

[paka]

Very sorry for late reply, for some reason I didn't get any information to my email address of any replies to the thread.

I solved the problem. Unnecessarily, I hurried with the post... Late hours, a bit of work. The problem was my time-step was exceeding the limit Courant number. The solution is to whether use coarser grid or simply decrease the time-step or use adjustable time-step. By changing this I was able to obtain the solution.

Many very thanks for the reply.
K