December 16, 2009, 15:57
|
Rewriting twoPhaseEulerFoam in conservative form
|
#1
|
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,912
Rep Power: 36
|
Hello,
I started to work on an improved version of a two-fluid solver with the goal of dealing with gas-particle flows with the traditional kinetic theory closures for the particle phase and, eventually, in future, more advanced techniques.
At first I thought to work on a two-phase code, because there still are a few questions to be addressed before adding complexity to the problem. So the steps I plan to follow are:
- Write a two-fluid solver which does not rely on the phase-intensive formulation of the phase momentum equations. The phase intensive form is of great help in stabilizing the solution when the phase volume fraction tends to zero, but it introduces non-conservative terms, which might lead to problems in the solution under certain conditions (See for example Parks et al., Nuclear Engineering and Design, Vol 239, Issue 11, November 2009, Pages 2365-2371)
- Implement a pressure-based compressible solver for the particle phase, to deal with the strongly non-linear behaviour of the particle pressure. After studying the existing algorithms for gas-particle flows, I think a pressure based solver might be the easiest approach to implement in OpenFOAM(r), compared to volume fraction based approaches. Moreover, looking at the functional form of the granular pressure in the dense limit, where the pressure diverges (the flow becomes incompressible), it becomes clear that solving for the granular pressure instead than for the volume fraction directly and then obtain the pressure from the equation of state is less troublesome.
Now, in doing this, there are some problems that need to be solved:
- Almost all the algorithms in the literature of multiphase flows are based on a staggered grid arrangement, while OpenFOAM uses colocated grids. This problem has been addressed already in twoPhaseEulerFoam, with Weller's pseudo-staggered approach, which relies on an appropriate use of the flux reconstruction to include certain contributions (gravity, drag, ...) in the momentum equation.
- The phase momentum equation is singular when the phase volume fraction becomes zero. This problem does not exist in the phase-intensive formulation, but it appears again when we consider the conservative form. A possible workaround is to define regions in the computational domain where the volume fraction alpha is smaller than a quantity alphaMin, and proceed to the solution only where alpha > alphaMin. To do this in OpenFOAM, one way is to define flags, and set the fvMaxtrix up so that it returns U = 0 where alpha < alphaMin. This seems to work correctly almost everywhere, but not at the interface between two phases. In a few cells accross the interface, (See MFIX numerics guide, www.mfix.org), the volume fraction of the dispersed phase is small, and the central coefficient becomes zero (or nearly zero) but the right-hand side of the momentum equation is not zero due to the presence of the fluid-phase pressure gradient and of the gravity term. This leads to a velocity peak at the interface that disturbs the solution significantly (it does not make the code crash in my implementation, and it does not cause oscillations to propagate in the solution, but the velocity peak is clearly wrong and negatively affects the volume fraction field for example). The MFIX numerical guide suggests to fix the problem solving for an approximate momentum balance in the interface cells, which are identified by looking for places where the central coefficient is very small, but I still need to figure out how to implement it "the OpenFOAM way" . If you have suggestions to resolve this problem in some way, help is welcome. To give an idea of the problem, I attach a picture of the velocity profile along the axis of a channel with particles at the top that are falling under gravity (beginning of the run)
Currently I have a rough implementation with a fictitious equation of state (I'm assuming the granular temperature to be constant), without the fix that causes the velocity peak at the interface.
P.S. Of course the code will be released, as soon as it works
__________________
Alberto Passalacqua
GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats (current status: http://albertopassalacqua.com/?p=1541)
OpenQBMM - An open-source implementation of quadrature-based moment methods.
To obtain more accurate answers, please specify the version of OpenFOAM you are using.
Last edited by alberto; December 16, 2009 at 16:44.
|
|
|