[kenyi89]

Dear Foamers,

I am currently looking into the DPMFoam code and I have trouble understanding the UcEqn.H file:

1. Given the UcEqn:
fvVectorMatrix UcEqn
(
fvm::ddt(alphac, Uc) + fvm::div(alphaPhic, Uc)
- fvm::Sp(fvc::ddt(alphac) + fvc::div(alphaPhic), Uc)
+ continuousPhaseTurbulence->divDevRhoReff(Uc)
==
(1.0/rhoc)*cloudSU
);

Why is the interface momentum transfer term (cloudSU) already included? Also, I would guess the '==' is already solving the equation, but this doesn't make sense to me.

2. Directly under the definition of UcEqn:
UcEqn.relax();
What does it mean to 'relax' an equation? I understand the general principle of relaxation but fail to understand how an equation statement can be relaxed.

3. Regarding solving the momentum predictor:
if (pimple.momentumPredictor())
{
solve
(
UcEqn
==
fvc::reconstruct
(
phicForces/rAUcf - fvc::snGrad(p)*mesh.magSf()
)
);
}
If the 'cloudSU' term from question 1 would already be included, it is now included twice in the solver, as phicForces also represents interphase momentum transfer. The answer to question 1 will probably also explain the answer to this question.


Any help or reference to proper documentation regarding DPMFoam/MP-PIC would be highly appreciated.

Kind regards,

Jeroen

[kenyi89]

Dear Foamers,

To answer my own question regarding relaxation of the momentum equation (question 2): It is described in Jasak's thesis on Finite Volume Method, equation 3.96:

In stead of relaxing the solution, which is done at a later stage in DPMFoam for the pressure, the coefficients of the momentum equation are relaxed to increase the diagonal dominance and hence the convergence rate. As far as I understood this is particularly important for steady state solutions, where the temporal derivative does not contribute to the diagonal.

Hope this helps anyone struggling as well

[kenyi89]

Again to answer my own question:

DPMFoam adds a semi-implicit treatment for the Uc term, meaning that cloudSU contains:

- drag (explicitly calculated, so handled as source term): drag_coefficient * (U_P - Uc_P)
- pressure gradient force (if added, also a source term)
- extra implicit part of the drag (drag_coefficient * Uc)
- extra MINUS explicit part of the drag (drag_coefficient * Uc)

The latter two sum to zero but is included to increase stability, as the drag itself is fully explicit. Notice the difference between the drag, which is calculated with the interpolated Uc value to the particle location, whereas the extra terms added contain simply the cell-mid Uc value. Any further explanation on why this is so would be helpful .

cloudSU has its source term part set to zero in the DPMFoam code, so eventually it only contains the third bullet from above (drag_coefficient * Uc, implicitly), this explains why it's included in the Uc equation, as it is an implicit term with Uc. cloudSUSu then contains the source part, which is drag + pressure gradient force - explicit drag part. cloudSUSu is included in the phicforces and ends up in solving the pEqn.

Hope this clarifies things a bit.

Jeroen

[d849c8]

your clarification is very helpful to me

[vonboett]

Hi Jeroen,
I am not so familiar with DPMFoam and my modified version is not stable yet, but
I think the extra terms account for the numerical oscillations you may get in the pressure equation when simply adding source terms in the cell center. The PISO algorithm goes for solving U at the faces to avoid the pressure-velocity coupling problem on collocated meshes (Ferziger & Peric 2002). But as I saw you already took a look at the checkerboarding at http://www.cfd-online.com/Forums/ope...tml#post547057

[mgao1]

Hi Jeroen,

I am also interested in how to calculate the source term. I know it is related to UTrans, but I could not find where the OpenFOAM defines the UTrans, could you please give me any clue. Thanks.

Ming