
[Sponsors] 
Instability solving lowdensity plume expansion with rhoCentralFoam 

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

#1 
New Member
Luka Denies
Join Date: Oct 2014
Posts: 28
Rep Power: 11 
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: 28
Rep Power: 11 
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. 

January 23, 2016, 09:24 

#3 
New Member
chirag khalde
Join Date: Sep 2011
Posts: 22
Rep Power: 14 
Hi LukaD,
Thanks for letting all know about the modification which wrks! I to tried to do something similar to avoid this problem. I limited p to minimum value of 0.00001 pa. Can u please have a look? I have uploaded the files http://www.cfdonline.com/Forums/ope...ntralfoam.html Thanks, Chirag 

January 23, 2016, 12:56 

#4  
New Member
chirag khalde
Join Date: Sep 2011
Posts: 22
Rep Power: 14 
Quote:
can you pls share your modified solver ? my id is chiragkhalde@gmail.com I will try to check whether it work for me too. Thanks in advance!! Chirag 

April 19, 2018, 10:19 

#5 
New Member
c
Join Date: Nov 2017
Posts: 4
Rep Power: 8 
Hi LukaD,
How do you pass the minE to the function that you have created? Cheers, Chris 

April 19, 2018, 22:11 

#6  
New Member
Luka Denies
Join Date: Oct 2014
Posts: 28
Rep Power: 11 
Quote:
I don't remember exactly (it was a long time ago) and I cannot access the code anymore as the work was for a previous employer. However, the lines above should give a clue. I made a new entry in controlDict, called "minTemperature" and somehow loaded that into the solver... But it was definitely not the hardest part for me, so you should be able to work it out I guess. Good luck! 

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


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
buoyantSimpleFoam and watertank  Tobi  OpenFOAM Running, Solving & CFD  100  December 18, 2022 09:15 
High Courant Number @ icoFoam  Artex85  OpenFOAM Running, Solving & CFD  11  February 16, 2017 14:40 
Moving mesh  Niklas Wikstrom (Wikstrom)  OpenFOAM Running, Solving & CFD  122  June 15, 2014 07: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 09:00 