[hsieh]

Hi,

I ran a case using simpleFoam with kEpsilon turbulence modeling. I got pretty good results (however, I had to set deltaT to 0.001 to prevent divergence).

I then ran the same case using turbFoam (same values for kEpsilon model) and it diverged pretty quickly : deltaT set to 1e-7, flow field initialized to 0 (velocity and pressure) except for the inlet, where velocity was given.

Any suggestion? Thanks!

Pei

[henry]

I don't understand your use of deltaT with simpleFoam. simpleFoam is a steady-state solver and doesn't use deltaT, at least not if you choose the steadyState time discretisation scheme in fvSchemes as you should.

Initialising the flow field to 0 is very difficult to start from because you are introducing an "numerical shock" and then transporting it. Try starting from a non-zero uniform field or even better a potential flow solution.

[hsieh]

Hi, Henry,

Thanks for the response.

I re-ran simpleFoam and it did not diverge this time, I must have fixed some problem before I changed deltaT to 0.001. However, the error in continuity is much higher when I set deltaT to 1 compared to when I set deltaT to 0.001. I wonder what does it mean when deltaT is 0.001 in simpleFoam.

But, the main question is turbFoam. I would like to capture the transient effect. The flow field was static initially (everything was 0), and at time = 0+, inlet velocity was set to a finite value. By setting the initial flow field to a uniform non-zero value (or from potential flow solution) is not what I am looking for. Maybe I need to specify the inlet velocity as a function of time?

Pei

[henry]

The continuity error is scaled with the time-step (see continuityErrs.H) which is appropriate for transient flow but not for steady-state. We should probably use a different definition for steady-state flow, do you have any preferences?

Having an initial velocity field of 0 but non-zero at the inlet is unphysical for incompressible flow, it violates continuity.

[eugene]

Would using SIMPLE instead of PISO help damp out this continuity violation?

[henry]

This is not a continuity voilation it's an issue of definition. How do you think the continuity error should be defined for a steady-state case where the time-step is irrelevant?

[hsieh]

Hi, Henry,

Although I agree with you that it is unphysical with a finite inlet velocity at time = 0+ while having a static flow field, but,

1) isn't the cavity case in icoFoam similar, that is, at time = 0+, impose a 1 m/s speed on the moving wall, while the rest of the flow domain is 0?
2) I had no problem running this type of problem using Fluent.
3) consider opening a value (in the mili-second time frame) to high pressure (where velocity quickly develop), maybe the solutions of the first few time steps are not accurate, but, the solution should "catch up" as time marches on.

Eugene, when you mentioned "continuity violation", do you mean using the SIMPLE algorithm in the transient calculation instead of PISO might help daming out the initial unphysical continuity violation and not the definition in steady state case, right?

Pei

[henry]

1) No, the cavity case has inifinte shear at the moving wall which does not introduce a continuity error.

3) I do not understand why you insist on starting from an unphysical condition when it is easy for you to make it physical either by choosing an appropriate initial velocity field or running a compressible code which can support the velocity-wave you insist on starting with.

[henry]

2) As far as possible we try to write codes which represent reality and operate with physical initial and boundary conditions. I do not know if Fluent is designed to operate in the same way.

[eugene]

Right. I dont know if it will help, I was just thinking out loud.

[hsieh]

Hi, Henry,

I agree with all your comments 100%. However, from a pure user point of view (I have been using Fluent for years and only few months on OpenFOAM), I am just trying to explore why I can do it in Fluent and not in OpenFOAM - most likey these two have some differences in implementation.

I am not insisting on using an incompressible code for a compressible problem. I am an engineer, not a research scientist. If I can get by using an incompressible code(although the first few time steps may be way-off) and obtain a decent solution after the first few time steps, it will be acceptable (in this case, why running a compressible code?). I will definitely use a compressible code if the first few time steps are also very important for my project of course.

At this point, I am still playing with every aspect of OpenFOAM. When things are different from my past experience with other CFD codes, I simply want to understand why. I did try to run this exact problem using sonicTurbFoam, but, right away I got a "nan" - I am sure that I did not set it up properly (still trying).

So far, my feeling is that OpenFOAM is very "strick" about things - I think it is a good thing that it forces you to set things up correctly. But, coming from a very user friendly commercail code, it takes time to get use to OpenFOAM.

Pei

[jack2000]

Dear all,

I try run one of the tutorial dambreak case (turbFOAM), but I always (in each time step) got zero result like shown in follows. I am confused by that. Why I can not repeat the result? Is that any parameter need to be changed, but it has not specified in the users' menu?

I would very appreciate if somebody can give me answer.

Best Regrads!

Jack


Mean and max Courant Numbers = 0 0
deltaT = 0.01
Time = 0.92

BICCG: Solving for gamma, Initial residual = 0, Final residual = 0, No Iterations 0
Liquid phase volume fraction = 0 Min(gamma) = 0 Max(gamma) = 0
BICCG: Solving for gamma, Initial residual = 0, Final residual = 0, No Iterations 0
Liquid phase volume fraction = 0 Min(gamma) = 0 Max(gamma) = 0
BICCG: Solving for gamma, Initial residual = 0, Final residual = 0, No Iterations 0
Liquid phase volume fraction = 0 Min(gamma) = 0 Max(gamma) = 0
BICCG: Solving for gamma, Initial residual = 0,


Final residual = 0, No Iterations 0
Liquid phase volume fraction = 0 Min(gamma) = 0 Max(gamma) = 0
ICCG: Solving for pd, Initial residual = 0, Final residual = 0, No Iterations 0ICCG: Solving for pd, Initial residual = 0, Final residual = 0, No Iterations 0ICCG: Solving for pd, Initial residual = 0, Final residual = 0, No Iterations 0time step continuity errors : sum local = 0, global = 0, cumulative = 0
ExecutionTime = 4.35 s ClockTime = 5 s

[edwin_gonzalez]

hi to all group,

i have some questions:

what so important are the time step continuity errors in a steady state simulation?

what happen if they are big?

edwin