View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002810 | OpenFOAM | Bug | public | 2018-01-15 16:31 | 2018-01-23 12:09 |
Reporter | christian23_rodrigues@hotmail.com | Assigned To | henry | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
Summary | 0002810: I believe the source term in continuity Eq. for phase2 in twoPhaseEulerFoam has wrong sign | ||||
Description | I 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 Reproduce | Download 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 Information | With 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. | ||||
Tags | multiphase | ||||
|
|
|
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. |
|
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. |
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 |