View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001748 | OpenFOAM | Bug | public | 2015-06-16 10:36 | 2015-06-19 16:45 |
Reporter | Assigned To | henry | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | Linux | OS | SUSE Linux Enterprise Server | OS Version | 11 |
Summary | 0001748: rhoCentralFoam: density non-conservation as temperature jump BC | ||||
Description | In rhoCentralFoam, if I set zero fixedValue boundary conditions for velocity, and fixed value BC for temperature that does not match the internal temperature, the density flux through that boundary is not zero. | ||||
Steps To Reproduce | Consider the attached case. Its initial conditions are uniform across all volume, and the boundary conditions are: for velocity, fixedValue zero on all patches; for pressure, zeroGradient on all patches; and for temperature, zeroGradient on two patches and fixedValue with different values on two other patches. The value set for temperature on one patch ("bottom") matches that inside the volume, and the value on the other patch ("top") does not match. Run rhoCentralFoam on it. For each time step, calculate the integral of density over the volume (I use IntegrateVariables filter in Paraview). This integral changes (increases) substantially over time, showing that density is not conserved, while it should be. Also, make rhoCentralFoam print its value of "phi" field and notice that its values on the "top" patch are essentially non-zero, thus showing where the density is gained from. | ||||
Additional Information | I am not sure that this is indeed a bug in OpenFOAM, maybe I am missing some special boundary condition class to be used in such a situation, but nevertheless my choice of BCs seems rather sensible, and the results do not seem so. I also have not been able yet to re-run this case on a latest OpenFOAM version. | ||||
Tags | No tags attached. | ||||
2015-06-16 10:36
|
|
|
This issue is a consequence of the outlet fix you proposed: http://openfoam.org/mantisbt/view.php?id=1548 If this change is reverted the flux through the walls is 0 as it should be. |
|
I have added code to ensure fixed value BCs are preserved even with the correction of #1548. This fix is in OpenFOAM-dev: commit 0d3bfc0a96bbaf4d549d663f1ddd5c23548c833f could you test it and if it is satisfactory I will apply it to OpenFOAM-2.4.x. |
|
This fix breaks #1548 again for me: the density in the testcase from #1548 again builds up near the boundary there instead of flowing freely. In fact, I'm afraid this problem can be solved by changing the way the interpolation is done, maybe some corrections to the main solver code is required. Currently I use a rather crude fix of manually setting the flux to zero when the boundary value of velocity is zero: ... phi = aphiv_pos*rho_pos + aphiv_neg*rho_neg; // force zero phi on patches where velocity is set to zero forAll(phi.boundaryField(), patchi) { if (max(mag(U.boundaryField()[patchi])) < 1e-10) phi.boundaryField()[patchi] = 0; } but this does not seem reliable or even proper for me. |
|
The problem with your #1548 case is that it has a fixed outlet (called inlet) pressure but the outlet flow goes supersonic which is unphysical. Currently the density boundary conditions are inferred from the pressure BCs which means that the outlet density is fixed (but updated due to changes in compressibility). The alternative would be to read the density and obtain the pressure from it; in this case what outlet BC (at the patch called inlet) would you specify for the density? |
|
Ok, I will look into this on the following week. |
|
#1548 reverted. |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-06-16 10:36 |
|
New Issue | |
2015-06-16 10:37 |
|
File Added: rhoCentralFlowBFlux.zip | |
2015-06-16 17:06 | henry | Note Added: 0004960 | |
2015-06-17 08:49 | henry | Note Added: 0004961 | |
2015-06-18 09:49 |
|
Note Added: 0004963 | |
2015-06-18 10:22 | henry | Note Added: 0004964 | |
2015-06-19 15:53 |
|
Note Added: 0004974 | |
2015-06-19 16:45 | henry | Note Added: 0004975 | |
2015-06-19 16:45 | henry | Status | new => closed |
2015-06-19 16:45 | henry | Assigned To | => henry |
2015-06-19 16:45 | henry | Resolution | open => fixed |