View Issue Details

IDProjectCategoryView StatusLast Update
0002810OpenFOAMBugpublic2018-01-23 12:09
Reporterchristian23_rodrigues@hotmail.com Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Summary0002810: I believe the source term in continuity Eq. for phase2 in twoPhaseEulerFoam has wrong sign
DescriptionI am replicating a simplified version of the laminar bubbling fluidised bed case with twoPhaseEulerFoam solver. To keep the test case simple, no gas feed is considered through the inlet and it is assumed that both phases are incompressible (rhoConst in EquationOfState). Therefore, it is expected that the fluidized bed will compact due to the effect of gravity.

In addition, some source terms have been considered, but only in a area defined by cellZone. This term should work as a mass source for phase1 and a mass sink for phase2, as described in fvOptions. From the figure presented in the attachments, it can be seen that the solid fraction in that area (in the middle of the domain) increases slightly, as expected.

However, the problem is that - with different densities between the two phases - the mass of phase2 that is leaving or getting inside the domain through the outlet does not match the differential in mass inside the domain due to the replacement of one phase by the other. For instance, if phase2 is "transformed" into phase1, and phase2 has lower density than phase1, then there should be some flow entering the domain through the inlet, which is not happening in the original version of the solver.

This can be solved by changing the minus sign in last term of contErr2 (the one related to fvOptions) - which is calculated in both "contErrs.H" and "correctContErrs.H" - by a plus.
Steps To ReproduceDownload the solver and the test case from:
https://holzmann-cfd.de/bugReport/bugReport_sourceTerm.zip

The solver is an adapted version of twoPhaseEulerFoam which includes a procedure to calculate the mass inside the domain and the flow rate through the patches. They are written during runtime (with keyword "Report"). Furthermore, the corrections proposed here is already included in both "contErrs.H" and "correctContErrs.H".

The other folder includes a test case where the simulation can be run by just typing "./Allrun" in the terminal (after compiling the solver mentioned above).

After running, check the log file for the lines starting with "Report". The value given in "Report-Time-average mass flux: Liquid mass" is now the same as the value calculated in "Report-Mass in domain Mass Integration".

This can be compared to what we get when we run the same test case after recompiling the solver back to the original OpenFOAM version (with minus before the fvOptions term, instead of plus).
Additional InformationWith different densities, the difference between the current mass inside the domain and the initial one should match the mass of the liquid phase leaving or entering the patch "outlet". Whether is goes in or out depends on the transformation, i.e. there should be some liquid entering the domain when solidification occurs. For simplicity, no solid flow is allowed through that patch.

In the original twoPhaseEulerFoam solver there seems to be some problems in this regard. The correction proposed here should fix this issue.
Tagsmultiphase

Activities

christian23_rodrigues@hotmail.com

2018-01-15 16:31

reporter  

sedWithSol.png (13,073 bytes)   
sedWithSol.png (13,073 bytes)   

Juho

2018-01-23 08:45

reporter   ~0009214

I took a quick look at your fvOption definition. It seems that you define a mass sink (negative source)for both phases. Not a sink and a source as you state in the description?

I don't know what you are trying to do, but you may want to take a look at reactingEulerFoam which supports different mass transfer mechanisms between the phases.

christian23_rodrigues@hotmail.com

2018-01-23 11:24

reporter   ~0009215

Actually, after your comment I analyzed again the test case and I realized I had two things wrong in my fvOptions:
1) I used the same name for the two source terms, and this would somehow not compile correctly in the dynamicCode folder (only one of the source terms was being defined there, even tough in the log.file both were being mentioned).
2) I was using the operator "=" in the source term equation. Replacing it by "+=" for the source and "-=" for the sink corrects the problem.

Somehow, the corrections I proposed in the bug report were giving me consistent results (even in terms of continuity balance). However, they are wrong based on what I just described.

Thank you for the clue and sorry for the confusion.

Issue History

Date Modified Username Field Change
2018-01-15 16:31 christian23_rodrigues@hotmail.com New Issue
2018-01-15 16:31 christian23_rodrigues@hotmail.com File Added: sedWithSol.png
2018-01-15 16:31 christian23_rodrigues@hotmail.com Tag Attached: multiphase
2018-01-23 08:45 Juho Note Added: 0009214
2018-01-23 11:24 christian23_rodrigues@hotmail.com Note Added: 0009215
2018-01-23 12:09 henry Assigned To => henry
2018-01-23 12:09 henry Status new => closed
2018-01-23 12:09 henry Resolution open => no change required