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/)
-   -   TRANSONIC FLOW in RHOSIMPLEFOAM (http://www.cfd-online.com/Forums/openfoam-solving/58755-transonic-flow-rhosimplefoam.html)

dinonettis July 4, 2008 08:04

Hi foamers, I'm studying a
 
Hi foamers,

I'm studying a transonic flow (Ma=0.75 Re=6.0e6) around a 2D rae2822 airfoil. Since the best strategy, from what I know, consist in reaching gradually the design Ma, then I used the following strategy:

-Ma 0.1 >> SimpleFoam
-Ma 0.3 >> SimpleFoam
-Ma 0.5 >> RhoSimpleFoam
-Ma 0.75>> RhoSimpleFoam (eventually RhoTurbFoam)

The computational domain consist in a simple square box, with the airfoil in the middle (see the picture below).
The boundary condition in the simpleFoam case are the following:

inlet: InletVelocity (U,k,epsilon,T>>fixed; p>>0grad)
outlet: PressureOutlet (U,k,epsilon,T>>0grad; p>>fixed)

Therefore up to Ma=0.3 the result obtained with these BC are acceptable.
When I change the solver, in order to solve a compressible steady-state flow (i.e. rhoSimpleFoam) with the same BC I do not reach the convergence. I think the problem is linked with the pressure boundary condition on the outlet. Therefore I change this boundary in a extrapolated outlet (also p 0grad).
Nevertheless the results are not encouraging as shown in the picture below:

http://www.cfd-online.com/OpenFOAM_D...ges/1/8213.jpg

Moreover this the log file for the last iterations:

Time = 310

DILUPBiCG: Solving for Ux, Initial residual = 0.0026651, Final residual = 3.0016e-07, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.0124881, Final residual = 1.21765e-06, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.00670324, Final residual = 7.27205e-07, No Iterations 1
GAMG: Solving for p, Initial residual = 0.938192, Final residual = 9.9076e-06, No Iterations 445
GAMG: Solving for p, Initial residual = 0.0347396, Final residual = 9.98619e-06, No Iterations 207
GAMG: Solving for p, Initial residual = 0.00952545, Final residual = 9.85373e-06, No Iterations 160
time step continuity errors : sum local = 4.04139e-05, global = -8.60266e-10, cumulative = 1.41743e-07
bounding p, min: -2395.45 max: 240228 average: 33802.6
rho max/min : 0.906574 0.114756
DILUPBiCG: Solving for epsilon, Initial residual = 0.00498808, Final residual = 1.94022e-06, No Iterations 1
DILUPBiCG: Solving for k, Initial residual = 0.00329573, Final residual = 1.69694e-06, No Iterations 1
ExecutionTime = 5058.19 s ClockTime = 29284 s

Time = 311

DILUPBiCG: Solving for Ux, Initial residual = 0.00274327, Final residual = 2.26323e-07, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.0123386, Final residual = 9.39338e-07, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.00680014, Final residual = 8.97438e-07, No Iterations 1
GAMG: Solving for p, Initial residual = 0.936856, Final residual = 9.44224e-06, No Iterations 464
GAMG: Solving for p, Initial residual = 0.0338914, Final residual = 9.9091e-06, No Iterations 217
GAMG: Solving for p, Initial residual = 0.0094568, Final residual = 9.91556e-06, No Iterations 168
time step continuity errors : sum local = 4.0787e-05, global = -2.10578e-09, cumulative = 1.39637e-07
bounding p, min: -2145.79 max: 244022 average: 36754
rho max/min : 0.925731 0.116199
DILUPBiCG: Solving for epsilon, Initial residual = 0.00498234, Final residual = 1.54389e-06, No Iterations 1
DILUPBiCG: Solving for k, Initial residual = 0.00330446, Final residual = 1.52035e-06, No Iterations 1
ExecutionTime = 5072.82 s ClockTime = 29381 s

Time = 312

DILUPBiCG: Solving for Ux, Initial residual = 0.00280222, Final residual = 3.42821e-07, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.0121609, Final residual = 1.02582e-06, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.00684187, Final residual = 8.18235e-07, No Iterations 1
GAMG: Solving for p, Initial residual = 0.936727, Final residual = 9.83742e-06, No Iterations 447
1 additional process aborted (not shown)

Finally I've tried to use rhoTurbFoam as well, but it seems that also this transient solver doesn't reach the convergence. In this case the "bounding" message concerns epsilon, but I think that the reason is still linked to the pressure behaviour.
Therefore what can I do to manage this issue???
thank you very much in advance.

dino

dinonettis July 4, 2008 08:06

ps: I forgot to specify that t
 
ps: I forgot to specify that the pressure I imposed, found in the literature, is:

43765 Pa.

dino

madad2005 July 4, 2008 09:19

Have you tried using RhoSimple
 
Have you tried using RhoSimpleFoam from fresh, rather than using the solution file from another case? The addition of shocks to the domain can cause a lot of problems, especially if your mesh isn't fine enough where the shock appears (discontinuities, etc.).

dinonettis July 4, 2008 13:56

Dear Adriano, thanks for yo
 
Dear Adriano,

thanks for your fast replay!!!
Actually I forgot to include the velocity picture in my previous post. Anyway, the solution imported from the simpleFoam case does not contain any shocks. The max velocity (given the freestream one equal to 100 m/s) is 125 m/s. Moreover the mesh is very fine, so that I can solve the boundary layer without wall functions! Therefore I think that it is a numerical problem that concerns the pressure solution, as you can see from the huge amount of iterations for the pressure compared with the other parameter.
So what do you think about??
thanks

dino

madad2005 July 4, 2008 14:21

Hi Dino, Sorry for the not
 
Hi Dino,

Sorry for the not so fast reply this time. Had a busy day! I noticed your problems with the GAMG solver. Could you try running the grid with the flow initiliased to M=0.75 from fresh, as I suggested before? I've always found running aerodynamic parts at transonic and higher speeds sensitive to initial conditions.

Something else about your case setup. You are using a velocity inlet, but running a compressible solver. I didn't think this was possible, because you now solve for denisty. I believed only Freestream boundaries (since you apply a Mach number condition rather than a velocity) or mass flow inlet (mdot = rho*A*U) could be applied. Maybe this is your problem? Could you try changing your velocity inlet to a mass flow inlet and see how it goes? Next, I'd try the freestream boundary.

Let me know how you get on.

dinonettis July 4, 2008 15:24

just a little question before
 
just a little question before I try your suggestions.....I can't find the mass flow inlet bc?!?
Anyway, I've a theoretical question as well.... since I'm new in the CFD field, I sincerely do not understand why an inlet velocity should give problems in compressible flow analysis! Moreover i've tried the freestream condition (inletOutlet for the velocity)in my past trials, but also in that case I had to specify the velocity and not the Mach num.
Thank you very much for you patience!!

dino

ryan_m July 4, 2008 20:59

Hey, Im relatively new to o
 
Hey,

Im relatively new to openFoam as well, but Ive done a few courses in aerodynamics. Not sure about the boundary condition (maybe one of the sonic tutes will have something), but in compressible flows, it is common to use the fact that the mass flow rate is constant throughout the flow field (especially if the flow is choked). Setting the velocity as constant at the inlet may cause some problems. This is because the flow field can 'adjust' itself to ensure that M=1 occurs only at the minimum area in the field (which would be the thickest point on the airfoil). This can mean the velocity at the inlet is forced to change, but the mass flow rate will remain constant.

Saying that, I have achieved good results using rhoSimpleFoam (only at M=0.45) using a velocity inlet. However, with your higher Ma number, I would recommmend the mass flow inlet. I have had no need to initialise my flow field with an incompressible solver either. I have found the major hurdle to getting good results is the mesh quality.

Hope this helps.

Ryan

madad2005 July 5, 2008 15:46

Mass flow inlet bc.. try this:
 
Mass flow inlet bc.. try this:

inlet
{
type massFlowRateInletVelocity
massFlowRate <yourvalue>

// mdot in kg/s

}

The mass flow inlet/freestream boundary conditions are required since density is being solved for (no longer constant). With freestream boundary you fixed a Mach number which is dependent on density, as is the mass flow inlet. What Ryan described seems fairly spot on. As he suggested, try to run RhoSimpleFoam without initialising to a previous solution. Initialise to M=0.75 and see how it goes. A fine mesh around and in the shock(s) is important for good results, but for 2D you should be able to get away with a mesh with less than 100k cells.

Good luck!

luca July 6, 2008 05:45

Hi Leonard, you cannot use
 
Hi Leonard,

you cannot use rhoSimplFoam for transonic flows. The problem is not the boundary conditions setup but the algorithm itself of the solver.
In the original rhoSimpleFoam the pressure equation has elliptic behaviour not suitable for transonic and supersonic flows in which you need hyperbolic-like pressure equation.

I suggest you to use rhoTurbFoam with the transSonic options or to modify by yourself the rhoTurbFoam solver

Enjoy

Luca

natrask October 21, 2009 12:02

What is it specifically about the rhoSimpleFoam algorithm that makes it unsuitable for transonic flows? Is it just the implicit treatment of the flux term in the pressure equation

i.e.

fvScalarMatrix pEqn
(
fvm::ddt(psi, p)
+ fvm::div(phid, p)
- fvm::laplacian(rho*rUA, p)
);

instead of

fvScalarMatrix pEqn
(
fvm::ddt(psi, p)
+ fvc::div(phi)
- fvm::laplacian(rho*rUA, p)
);

or is there something more subtle?

-Nat


All times are GMT -4. The time now is 01:45.