
[Sponsors] 
Instability solving lowdensity plume expansion with rhoCentralFoam 

LinkBack  Thread Tools  Display Modes 
November 5, 2014, 10:05 
Instability solving lowdensity plume expansion with rhoCentralFoam

#1 
New Member
Luka Denies
Join Date: Oct 2014
Posts: 10
Rep Power: 2 
Dear all,
I'm working on the simulation of an expanding nozzle plume using rhoCentralFoam. I am currently trying the replicate the results obtained by Ivanov et al. in http://arc.aiaa.org/doi/abs/10.2514/...ournalCode=jpp They model the nozzle and the core flow with NavierStokes and then use DSMC to calculate the outer flow. I am only interested in the NavierStokes part. I've successfully created a case which computes the conditions inside the nozzle by using totalPressure and totalTemperature conditions for the inlet. For the outlet, I use a waveTransmissive boundary condition on the pressure, and zeroGradient on the temperature. Velocity is set to zeroGradient for both cases, as the nozzle flow is pressuredriven. The results of the simulation in OpenFOAM match the results in the paper almost exactly. However, when I try to also model the expansion of the flow into vacuum, I run into problems. The domain I use is similar to the one used in the paper for continuum solutions. I initialize the pressure with a modified Lagrangian solver to obtain a smoothed pressure field (from 17 bars at the inlet to 1e4 Pa at the outlet patches). When I run the case with the second order discretizations, it blows immediately. Using the following gradScheme, I am at least able to get it to run for 1e4 seconds. This solution is relatively close to convergence, but there is severe numerical dissipation in it. This can be seen from the attached velocity field, with a very thick boundary. Code:
gradSchemes { default cellLimited Gauss linear 1; } I am fully aware that a large part of this domain (especially the top left part near the nozzle lip) is too rarefied for NavierStokes to be accurate. However, this should not mean that the simulation should blow up, only that the solution cannot be trusted in this part of the domain. I have found out that the size of the domain strongly influences the behaviour of the core flow, so I do not want to simply make the domain smaller to avoid this behaviour. If anyone could give me some hints for where to look, I would be very happy. 

November 10, 2014, 04:13 

#2 
New Member
Luka Denies
Join Date: Oct 2014
Posts: 10
Rep Power: 2 
Hey all,
I've digged into this problem a bit deeper. It turns out that the authors of the original paper on rhoCentralFoam (Implementation of semidiscrete, nonstaggered central schemes in a colocated, polyhedral, finite volume framework, for highspeed viscous flows by Greenshields et al.) already recognized and mentioned this problem. The issue is that temperature is not solved for directly, instead rhoCentralFoam solves for the energy per grid point. From this energy, the kinetic energy is subtracted to find the internal energy and thus the temperature: Code:
e = rhoE/rho  0.5*magSqr(U); However, the problem at hand was not solved using this approach. In the end, it became clear to me that it was to be expected that negative temperature will almost unavoidably occur somewhere in the domain with this solver setup. As we are dealing with very low temperature and high velocity flows, the smallest error can cause a negative internal energy. Therefore, I cheated somewhat. I implemented a minimum temperature by changing the line above to this: Code:
e = max(rhoE/rho  0.5*magSqr(U),minE); I recognize that this is in fact cheating, but preliminary results indicate that this indeed makes it possible for the solver to converge to my validation case. I hope that it will be possible after initial transients to set the minimum temperature to zero without obtaining a negative temperature anywhere in the domain. 

Tags 
negative density, nozzle, plume, rhocentralfoam 
Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
buoyantSimpleFoam and watertank  Tobi  OpenFOAM Running, Solving & CFD  48  December 26, 2014 09:49 
Moving mesh  Niklas Wikstrom (Wikstrom)  OpenFOAM Running, Solving & CFD  122  June 15, 2014 06:20 
rhoSimplecFoam Mach0.8 no pressure values  CFDnewbie147  OpenFOAM Running, Solving & CFD  16  November 23, 2013 06:58 
Why RNGkepsilon model gives floating error  shipman  OpenFOAM Running, Solving & CFD  3  September 7, 2013 08:00 
High Courant Number @ icoFoam  Artex85  OpenFOAM Running, Solving & CFD  9  January 3, 2012 09:06 