CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Using a variable (increasing) inlet to get an easy convergence/initialization ? (http://www.cfd-online.com/Forums/openfoam-solving/115314-using-variable-increasing-inlet-get-easy-convergence-initialization.html)

fredo490 March 28, 2013 03:32

Using a variable (increasing) inlet to get an easy convergence/initialization ?
 
Dear all,
I'm running some simulations with rhoSimplecFoam (k-epsilon, Air) and I encounter some convergence / initialization problems. I mostly run my case at Mach 0.3 and 0.4 and I often get divergence even with simple geometries such as Naca Airfoils or Cylinders.

I tried different techniques:
- initialize the flow with a potentialFoam
- initialize the velocity internalField at different speed (0 to 80m/s)
- play with the under relaxation numbers ...
- using upwind scheme
- use different meshes (structured, unstructured, yPlus from 0.1 to 30,...)

After many tries, I found that a good way to avoid divergence and get convergence is to slowly increase the inlet velocity value ! For example, I start at 2m/s, then 5m/s, then 10m/s and so on until the actual velocity. However, this technique is "slow" and requires some manual change.

First, is this "initialization" ok ? I mean, I didn't see anybody using such a technique, maybe there is a problem I don't know about.

Second, is there a way to make this automatically ? I found this link but it looks old and unusable in OF2: http://www.idurun.com/?p=512

My inlet is:
Code:

alphat:
        type            calculated;
        value          uniform 0;

epsilon:
        type            fixedValue;
        value          uniform 2.15e-1;

k:
        type            fixedValue;
        value          uniform 1.6e-2;

mut:
        type            calculated;
        value          uniform 0;

p:
        type            zeroGradient;

T:
        type            fixedValue;
        value          uniform 281.4;

U:
        type            fixedValue;
        value          uniform (81.02 0 0);

My outlet is:
Code:

alphat:
        type            calculated;
        value          uniform 0;

epsilon:
        type            inletOutlet;
        inletValue    uniform 2.15e-1;
        value          uniform 2.15e-1;

k:
        type            inletOutlet;
        inletValue    uniform 1.6e-2;
        value          uniform 1.6e-2;

mut:
        type            calculated;
        value          uniform 0;

p:
        type            fixedValue;
        value          uniform 95650;

T:
        type            inletOutlet;
        inletValue    uniform 281.4;
        value          uniform 281.4;

U:
        type            inletOutlet;
        inletValue    uniform (81.02 0 0);
        value          uniform (81.02 0 0);

My wall is:
Code:

alphat:
        type            alphatWallFunction;
        value          uniform 0;

epsilon:
        type            compressible::epsilonWallFunction;
        value          uniform 2.15e-1;

k:
        type            compressible::kqRWallFunction;
        value          uniform 1.6e-2;

mut:
        type            mutkWallFunction;
        value          uniform 0;

p:
        type            zeroGradient;

T:
        type            zeroGradient;

U:
        type            fixedValue;
        value          uniform (0 0 0);

My internalFiel is:
Code:

alphat:
        value          uniform 0;

epsilon:
        value          uniform 2.15e-1;

k:
        value          uniform 1.6e-2;

mut:
        value          uniform 0;

p:
        value          uniform 95650;

T:
        value          uniform 281.4;

U:
        value          uniform (81.02 0 0);


olivierG March 28, 2013 10:04

hello,

Which field is diverging ? My guess would be turbulence model :
=> try turbulentIntensityKinetics... for k, and turbulentMixingLenght... for epsilon, and relax k,epsilon (if steady solver).

If you would to use a ramped velocity inlet, take a look at flowRateInletVelocity or uniformFixedValue, and specify a velocity changing in time (or iteration), like:
Code:

type uniformFixedValue;
uniformValue table
(
(0 (0 0 0))
(100 (100 0 0))
);

which start with 0 velocity at time 0, then grow to Ux=100m/s at time 100, and stay after that (since outOfBound clamp; is the default).

regards,
olivier

JR22 March 28, 2013 14:54

Look at the motorbike tutorial (Allrun), which uses potentialFoam to get the fields initially, then it runs the actual solver. Would this work for you?

MY BAD: You alread tried this.

fredo490 March 29, 2013 04:23

Thx Olivier for your advices.

0) the diverging field is most of the time the pressure that leads to a Floating Point Exception (caused by the thermo model).

1) I've tried to change my k and epsilon settings (inlet and relax number) but it doesn't change anything.

2) The technique of the Table works well but I need many steps to reach my final velocity.

3) I've also tried to use the flowRateInletVelocity inlet but it also often diverge after only 2 or 3 iterations (the pressure starts to diverge first). Moreover, using this kind of Inlet, I get some strange oscillation of the pressure/density through my domain. It's like a wave going from the inlet to the outlet and coming back (once my pressure inlet > pressure outlet and then two iteration later it is pressure inlet < pressure outlet and so on).

fredo490 March 29, 2013 06:00

To make the things simple, here is my current case (3.8 MB) :
http://www.fredo490.fr/public/rhoSim...der_Vinlet.zip

It is a structured 4 inch cylinder at 81.02m/s (95650 Pa and 8.2C).

olivierG April 2, 2013 06:22

hello,

You may try to modify the outlet BC:
-p : totalPressure
- U pressureInletOutletVelocity (or pressureInletVelocity / pressureDirectedInletVelocity / ...)

regards,
olivier

fredo490 April 2, 2013 09:02

thx for your advice.

For those who want, I found a good source for the table inlet: http://www.openfoam.org/version2.1.0...conditions.php

Also, I found that using a "Laplacian schemes linear limited 0.5" helps a lot.

Tobias Adam April 9, 2014 08:01

is it possible to use such table options for the SRF or MRF - options in order to increase the rotational speed?

alexeym April 9, 2014 09:35

Well,

in case of MRF you can do it cause omega is defined as follows:

Code:

//- Angular velocty (rad/sec)
autoPtr<DataEntry<scalar> > omega_;

while in SRF there's no such possibility as RPM is defined as

Code:

//- Revolutions per minute
scalar rpm_;

Surely you can make your own SRFModel where RPM is simillar to omega in MRFModel.


All times are GMT -4. The time now is 23:09.